Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: The actual code of HHH
Date: Thu, 27 Feb 2025 20:00:16 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <df6bd0f4c3172f1b1597dbbe3772e3bc63bfb5f4@i2pn2.org>
References: <f73c3b97590a4d189e33a2cf255ed3337e56d3cf@i2pn2.org>
 <vppdf8$32jp4$1@dont-email.me>
 <IHCdnbVJVtETLF36nZ2dnZfqn_SdnZ2d@brightview.co.uk>
 <vpqedi$37v45$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Feb 2025 01:00:16 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2112681"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vpqedi$37v45$3@dont-email.me>
Content-Language: en-US

On 2/27/25 2:28 PM, olcott wrote:
> 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.
> 

Wrong, HHH1 shows that it does. The problem is you like to change the 
program by changing HHH and thus changing the code that DD uses, that 
must be part of the input.

This just shows that you are just a pathological liar.

> EVERYTHING ELSE IS A RED HERRING

  No, your claiming lies is the red herring, and show your stupidity.

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