Liste des Groupes | Revenir à theory |
On 26/07/2024 16:56, olcott wrote:If HHH gets the correct answer in an impure way then it onlyThis is meant for Mike, Joes and Fred don't have the technical competence to understand it.Well, the first two claims are literally untrue - outer HHH effectively uses the static mutable data to pass flags to the inner HHH that modify its behaviour. The Root flag below is derived from the actual static data and causes inner HHH to totally skip its own abort logic!
>
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
>
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
You seem to acknowledge this, but claim it does not matter for various reasons, because whatever mistakes you are making, what finally gets printed out is saying the right thing!
The problem with this attitude is that when you describe your ideas and present the printed output, you say that HHH is "simulating" DDD, and people know what simulating means, and everyone has expectations of what that implies. You are happy to use those expectations when it goes along with what you want to claim, but try to conceal that those expectations are unjustified because what you are doing is not "proper simulation" as everybody would understand it.It does not have any effect on the simulation. It only gets
You can't have it both ways.It may seem that way if you are not paying close enough attention
The way to avoid all such concerns is to implement simulation correctly, like you claim to have done. Simulation is not /just/ the step by step simulation provided by libx86emu(sp?) -Yes it is. That *is* what simulation is.
your entire computation environment needs to correctly work together so that the end-to-end effect is that simulated code exactly follows the behaviour of the original code, at least up to the point where the simulator aborts.It has done that for three years and you never bothered to pay
Put differently, you also need to simulate the /correct/ instructions and data.The instructions *are* the data. A sequence of these instructions
The same applies to when you try to "copy" code,I don't try to copy code. libx86emu gets confused with
as in your H1 and HHH1: by definition of "copy" [as understood by everybody here] the behaviour of the copied code must exactly match that of the original code - otherwise it is simply not a proper "copy" by definition.There is no copy. It is always the exact same integer
>
As a joke alternative you could stop claiming to simulate or copy anything, and say instead you are misulating and pocying code! You could say "HHH misulates DDD and sees that DDD will never halt" but obviously people will just say "What's misulating, and why should misulating (whatever it is) allow HHH to see things about DDD?" You see - from your perspective that would be hopeless for your wider scope argument which attempts to invalidate the Linz/Sipser proofs. Similarly if you claim that you "pocyed" HHH to HHH1 and they have different results when given input DDD, people will just look blank - what's "pocying" and why would anyone expect a pocyed routine to give the same result as the original routine?That you disagree that the simulation is correct without being
No, none of that flies. It was a joke, but with a sensible aim - to convince you that for your wider scale arguments you need simulating (and copying) to have their correct meanings as everybody here will understand them. No good saying "they mean something else, but it doesn't matter because what my program finally writes out is TRUE".
Of course none of that will convince you of anything and you'll just continue.
>Your concept of master/slaves simulators is broken. There are outer/inner simulators but that is just a relative term, and all simulated code (at whatever level) needs to have the same behaviour as the unsimulated code.
I could change the code so that the slave instances can and do
try to form a halt status decision on the basis of the execution
trace that they do have.
If your simulation was correctly designed/implemented this would just work. (Of course, HHH has to correctly use the DebugStep() (et al.) primitive ops to gather what it needs to make its decision, no cheating with globals etc..)
I know you've said you don't have time to think about how to do this correctly. That's fair enough, but in the meantime you should not claim that your incorrect implementation proves your conclusions!Anyone having sufficient knowledge of the x86 language can verify
To be fair, you shouldn't need x86utm.exe in your arguments - it is not the Appeal To Authority that you imagine it to be! All of your arguments could just be phrased in pseudo-code and there would not be any disagreement about how that would behave by posters here. Of course, your ideas expressed that way would still be Wrong, and nobody would agree with them, but that's the case anyway when you try to bring in x86utm!That you disagree that the simulation is correct without being
Les messages affichés proviennent d'usenet.