On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical competence to understand it.
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.
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!
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.
You can't have it both ways.
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?) - 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. Put differently, you also need to simulate the /correct/ instructions and data.
The same applies to when you try to "copy" code, 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.
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?
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.
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.
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.
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! 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!
There is no sense in doing that because they can't possibly have
enough data, they will always be one whole execution trace behind
the next outer instance of HHH.
Well it's your code so correct it or don't correct it...
The sense in doing it would be:
1) Pride in having implemented something without botching it
2) Slight increase in the reliability of conclusions base on running x86utm simulations.
[But in any case you won't be able to claim x86utm "proves" any of your claims.
That's just not how proofs work...]
3) Surely there must be a (3). Um, third time lucky?
Regarding (2) I've found the answer to my recent question of what you had done wrong in the whole "DDD simulated by HHH has different behaviour to DDD simulated by 'copy' HHH1". It turns out HHH1 wasn't a copy, it was a "pocy" [the word I coined above] :)
So what was the coding error? To remind us, here's a comparison of the different behaviour:
[VIEW WITH FIXED FONT!!]
HHH1 (DDD) HHH (DDD)
-----------------------------------------------------------------
1 main () main ()
2 HHH1 (DDD) HHH (DDD)
4 Simulate (DDD) Simulate (DDD)
5 | DDD() | DDD()
6 | HHH (DDD) | HHH (DDD)
7 | Simulate (DDD) | Simulate (DDD)
8 | | DDD() | DDD()
9 | | HHH (DDD) | HHH (DDD)
10 | | Simulate (DDD) Abort
11 | | DDD() ret 0
12 | | HHH (DDD) ret 0
13 | Abort
14 | ret 0
15 | ret
16 ret 1
17 ret 0
The question you never managed to answer was why on the right does HHH [line 2] spot that HHH is called below [lines 6,9] in "infinite recursive simulation", while on the left HHH1 [line 2] does not make the same decision, despite being a "copy" of HHH on the right?
The explantion is down to your misuse of mutable static variables in HHH/HHH1 to store their execution traces covering all sub-simulations. HHH and HHH1 each have /their own/ static execution trace table! So :
- HHH [line 2, RHS] has its own trace table which is explicitly updated
by (arbitrarily nested) sub-simulations, BUT ONLY BY SIMULATIONS OF
HHH1!!! So it "sees" the calls to HHH [lines 6,9] and matches
its [unsound] abort pattern.
- HHH1 [line 2, LHS] has its own trace table which is explicitly updated
by (arbitrarily nested) sub-simulations, BUT ONLY BY SIMULATIONS OF
HHH1!!! Simulations of HHH will update the execution trace in HHH's
static variable. So HHH1 completely fails to "see" the calls to HHH
[lines 6,9] and so never matches its [unsound] abort pattern. Instead
it continues simulating until DDD terminates, correctly deciding that
DDD terminates.
So... as suspected the reason HHH(DDD) and HHH1(DDD) see different behaviour is simply that HHH1 is not a proper copy of HHH - it's a "pocy"! And the coding error is the misuse of mutable static variables which you already know is wrong, although you are reluctant to correct.
It is of course nothing to do with "pathelogical self reference" or any such nonsense - it's just WRONG CODING. Note that your HHH/HHH1 are trying to "push" data [inner simulation trace records] to the outer simulators, which is Wrong Design. Right Design is for the outer simulators to dig into the inner simulations to scrape what data they need. If HHH/HHH1 worked this way they would both have the same behaviour as common sense requires, and you wouldn't be able to use this example to back up your claims of different behaviour. In fact both HHH/HHH1 would then report DDD as non-halting, which is wrong due to the unsound abort pattern they both use - but at least it would be consistent, as required for a proper copy (rather than some kind of pocy).
Regards,
Mike.
>
> As they are the slaves perform their proper function of showing
> the actual behavior of DDD correctly emulated by HHH.
>
> u32 Decide_Halting_HH(u32** Aborted,
> u32** execution_trace,
> Decoded_Line_Of_Code** decoded,
> u32 code_end,
> u32 End_Of_Code,
> Registers** master_state,
> Registers** slave_state,
> u32** slave_stack,
> u32 Root)
> {
> u32 aborted_temp = 0; // 2024-06-05
> u32 Current_Length_Of_Execution_Trace = 0;
> while (aborted_temp == 0) // 2024-06-05
> {
> u32 EIP = (*slave_state)->EIP; // Save EIP of this instruction
> DebugStep(*master_state, *slave_state, *decoded); // Execute it
> if (EIP > Last_Address_Of_Operating_System()) // Ignore OS code
> {
> PushBack(**execution_trace, (u32)*decoded,
> sizeof(Decoded_Line_Of_Code));
> }
>
> if (EIP == code_end)
> return 1;
>
> if (Root) // Master UTM halt decider
Root is derived from misused static data within HHH, and is 1 if this is the outer HHH, and zero if it is an inner instance, enabling inner simulations to behave differently to outer ones.
This is Wrong Design.
> {
> u32* address = (u32*)**execution_trace;
> u32 size = (u32)*(address-1);
> // Detects slave appended an instruction to its execution_trace
> if (size > Current_Length_Of_Execution_Trace)
> {
> Current_Length_Of_Execution_Trace = size;
> aborted_temp = // 2024-06-05
> Needs_To_Be_Aborted_HH
> ((Decoded_Line_Of_Code*)**execution_trace);
> }
> }
> }
> if (aborted_temp == 1) // 2021-01-26 Must be aborted
> return 0;
> return 1; // 2021-01-26 Need not be aborted
> }
>
…