Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott 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: References: 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: 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