Re: The actual code of HHH

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, as your "programs" don't meet the requirements of being actual programs.
YOur problem is you just don't understand what that means, an thus you think it is ok to just make up lies.
A simulated machine can not know it is being simulated or the simulation is not correct, because the only information a program can use is what is in its input.
The simulator doesn't allocate part of its tape for the simulated version, but creates a "virtual" tape within its tape to encode the current state.

 In any case this is all totally moot until one understands
that DD correctly simulated by HHH and

Which is totally moot as HHH doesn't correctly simulate DD, since it aborts and returns an answer.
You are just demonstarting your stupidity, thinking that one program can be doing two different things at once.

 Ĥ.q0 ⟨M⟩ ⊢* embedded_H ⟨M⟩ ⟨M⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨M⟩ ⊢* embedded_H ⟨M⟩ ⟨M⟩ ⊢* Ĥ.qn

And if embedded_H doesn't act exactly like H, your input is a lie.
WHich means that your H must be wrong, as it answers yes for a machine that didn't halt or no for a machine that does halt.

 Linz ⟨Ĥ⟩ correctly simulated by Linz Ĥ.embedded_H
specify non terminating behavior to their termination
analyzer partial halt decider.
 

Nope, because again, if embedded_H goes to n, it did so by not simulating the input correctly, since it aborted its simulation.
Your mind, because it insists on the existance of a truth fairy to make your impossible happen, just lies to you that it can do that.