Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: The actual code of HHH
Date: Thu, 27 Feb 2025 13:28:51 -0600
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vpqedi$37v45$3@dont-email.me>
References: <f73c3b97590a4d189e33a2cf255ed3337e56d3cf@i2pn2.org>
 <vppdf8$32jp4$1@dont-email.me>
 <IHCdnbVJVtETLF36nZ2dnZfqn_SdnZ2d@brightview.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Feb 2025 20:28:51 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a411d0b11a3cdd795023b06d93853175";
	logging-data="3406981"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19+Q6fqpZwAHd0iygndikpL"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:3G40vGUBd5QUkMVKoFOFm/MOfvM=
X-Antivirus-Status: Clean
In-Reply-To: <IHCdnbVJVtETLF36nZ2dnZfqn_SdnZ2d@brightview.co.uk>
Content-Language: en-US
X-Antivirus: Norton (VPS 250227-10, 2/27/2025), Outbound message
Bytes: 5401

On 2/27/2025 12:40 PM, Mike Terry wrote:
> 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.
> 

The machine code of DD emulated according to the behavior
that this machine code specifies cannot possibly reach its
own "ret" instruction and terminate normally.

EVERYTHING ELSE IS A RED HERRING

> 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.
> 


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer