Path: ...!Xl.tags.giganews.com!local-4.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Feb 2025 18:40:14 +0000
Subject: Re: The actual code of HHH
Newsgroups: comp.theory
References: <f73c3b97590a4d189e33a2cf255ed3337e56d3cf@i2pn2.org>
 <vppdf8$32jp4$1@dont-email.me>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Thu, 27 Feb 2025 18:40:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
MIME-Version: 1.0
In-Reply-To: <vppdf8$32jp4$1@dont-email.me>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <IHCdnbVJVtETLF36nZ2dnZfqn_SdnZ2d@brightview.co.uk>
Lines: 63
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WntkzMtzL/IBvwrlYli0cyFxgIzSgvR1Pa2GuUIXmKnuMgpfDJq2t9li5ke8tiK/tcAz1KjZZA4JthZ!JtnqszHLpaJlXd4RhPYXY3ASUGDTnJ8Uc/FS2BwCWTTn/OpCXo2eGPIdTPvddgsGjVRqfmH4nN8N!sTBpXO56zs07g+c68ijJK0nmDrs=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 4831

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.

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.