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: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: The actual code of HHH
Date: Thu, 27 Feb 2025 21:07:26 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <69ea9e900ed4aa9b3325b011a95dde1c2b5fd69e@i2pn2.org>
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
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Feb 2025 21:07:26 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2082623"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0

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?

> ..and the nop instruction is 0x90, hence the first-through test for
> 0x90909090.
That was the bit I'm missing.

> 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.
-- 
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.