Re: The actual code of HHH

On 2025-03-01 01:46:06 +0000, olcott said:

On 2/28/2025 8:30 AM, Richard Damon wrote:

On 2/27/25 9:05 PM, olcott wrote:

On 2/27/2025 7:41 PM, Mike Terry wrote:

On 27/02/2025 21:07, joes wrote:

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?

 No, the DATA1/DATA2 memory is part of the program /code/ of HHH, initialised to NOP instructions. Also there are similar areas in the variation functions HHH1 and so on.
 Normally if you're writing C code and you need a static variable you would write e.g.
 u32 HHH(ptr P)
{
   u32* Aborted;
   static u32* execution_trace = NULL;  /* <===== */
   u32  End_Of_Code;
   ..
   if (execution_trace == NULL)
   { /* first time (outer HHH) */
     execution_trace = Allocate (sizeof(Decoded_Line_Of_Code) * 10000);
   }
   ...
}
 Done this way, execution_trace is naturally in the program /data/ segment, not the /code/ segment. Initialising it to NULL is natural and I think the default anyway for static data.  PO could disassemble HHH function without encountering the null bytes as code.  But instead he wants the DATA1 /code/ text to contain the Allocated memory address, and DATA1 is part of the /code/ segment so he initialises it to NOPs to avoid problems disassembling it.  He sets execution_trace to point to DATA1 introducing an extra level of redirection everywhere it's used, in case you were wondering about extra * appearing in the code in various places.  :)  The DATA1 is later updated with the pointer from Allocate() but that is done indirectly via **execution_trace = ... (note extra *)
 Mike.
 

 My idea of all of this is that a TM could do this same
sort of thing. The outer TM knows its own tape and
allocates a portion of this tape to slave instance of
itself. Each instance of these TM's thinks that a single
execution_trace belongs to itself alone.

 A TM Could not do the same sort of thing,

 Mike has already agreed that a TM that is a UTM
can examine every aspect of the internals of its
slave UTMs.
 None of the details of HOW HHH determines that
its finite string input specifies non terminating
behavior is relevant UNTIL AFTER IT IS UNDERSTOOD THAT
ITS FINITE STRING INPUT SPECIFIES NON TERMINATING BEHAVIOR.

Understanding is not relevant. A proof would be if there were one.
As long as there is none it is sufficient to say that the claim is
unproven.
--
Mikko