Re: The actual code of HHH

Am Thu, 27 Feb 2025 18:40:14 +0000 schrieb Mike Terry:

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.

Thank you.

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:

So the memory is garbage before and doesn't get updated afterwards?

..and the nop instruction is 0x90, hence the first-through test for
0x90909090.

That was the bit I'm missing.

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.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.