Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: The actual code of HHH
Date: Sat, 1 Mar 2025 10:13:31 +0200
Organization: -
Lines: 105
Message-ID: <vpufjb$4ucu$1@dont-email.me>
References: <f73c3b97590a4d189e33a2cf255ed3337e56d3cf@i2pn2.org> <vppdf8$32jp4$1@dont-email.me> <IHCdnbVJVtETLF36nZ2dnZfqn_SdnZ2d@brightview.co.uk> <69ea9e900ed4aa9b3325b011a95dde1c2b5fd69e@i2pn2.org> <lf-cnWK8e7fTiVz6nZ2dnZfqnPidnZ2d@brightview.co.uk> <vpr5le$3bvlg$1@dont-email.me> <c8e04c99badc0d6fe5176e67a327e95073b2d324@i2pn2.org> <vptosu$3st19$16@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 01 Mar 2025 09:13:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3c2cdfc6a621b8df7395d6a65111664f";
	logging-data="162206"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ep1XNzLdrBqzx9qwB1/3V"
User-Agent: Unison/2.2
Cancel-Lock: sha1:ASPg7jvRSKvUnzCu64obyUSXWTQ=
Bytes: 5948

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