Re: The actual code of HHH

On 27/02/2025 10:06, Mikko wrote:

On 2025-02-26 21:52:31 +0000, joes said:
 

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081
In line 1137, we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded, &code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

 The variable execution_trace is a pointer to a pointer to a 32 bit
unsigned int. The function Init_Halts_HH may update the pointer
*execution_trace or the number **execution_trace. The special value
0x90909090, when interpreted as a fragment of a program, means four
no operation instructions. That many no operation instructions is not
used in the compiled code so it can be used as a speial value where
otherwise instrunctions generated by the compiler are expected.
 

This whole 0x90909090 thing is a bit of a red herring.  Best just view it as an initial value, so the code that tests for it is looking for a "first time through" condition.  PO's design needs a single execution trace table which is allocated by the outermost HHH, then used by all the inner HHHs to send their trace data to the outermost HHH for analysis.  Given this design, the inner HHHs must not allocate another trace table.  Also they skip the abort analysis logic, making their simulated code behaviour different from the outermost HHH.
Why 0x90909090?  When you look at the HHH code, you probably wonder "WTF is all this DATA1, DATA2 and related assembler stuff for?"  The answer is it's not really for anything useful!  It was just some experiment PO was conducting at some point to show to himself that the code of HHH could update itself if it wanted to.  The DATA1/DATA2 areas hold the direct addresses to global data areas like the execution trace table.  PO initialises them with:
#ifdef _WIN32
   __asm nop  // The purpose of creating static local memory
   __asm nop  // directly in the function body is to make it
   __asm nop  // clear that a Turing machine computatation has
   __asm nop  // this ability by simply writing to its own tape
#elif __linux__
   __asm__("nop");  // The purpose of creating static local memory
   __asm__("nop");  // directly in the function body is to make it
   __asm__("nop");  // clear that a Turing machine computatation has
   __asm__("nop");  // this ability by simply writing to its own tape
#endif
..and the nop instruction is 0x90, hence the first-through test for 0x90909090.
Why did PO use nop instructions here?  Well, he has code elsewhere that disassembles all the halt7.c functions as part of x86utm.exe output listing.  That code would expect DATA1/DATA2 to contain valid x86 instructions or it would choke.  The comments in the code above shows that he doesn't understand TMs and the concept of code vs data, and the fact that a TMs code is not on its tape etc. etc. etc.
I say it's all a red herring, because all the above is exactly equivalent to a much simpler (and transparent) use of a static variable to hold these global data addresses.  Perhaps PO thought that by doing it this way he was avoiding the use of mutable static data or whatever.  Just mentally replace all the lines 1086-1129 with two lines declaring 32-bit static pointers!  (Don't worry /why/ he did all this or what he thought it might achieve...)
Mike.