Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: D correctly simulated by H proved for THREE YEARS ---
Date: Tue, 11 Jun 2024 12:00:05 +0300
Organization: -
Lines: 71
Message-ID: <v493ml$vlup$1@dont-email.me>
References: <v45tec$4q15$1@dont-email.me> <v46drt$3i580$1@i2pn2.org> <v46ipg$bqg4$1@dont-email.me> <v476c3$ggn5$12@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 11 Jun 2024 11:00:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d85ead99d95209551742cb12f3fa5675";
	logging-data="1038297"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pS1/dIuNV2LRGBsmm73ja"
User-Agent: Unison/2.2
Cancel-Lock: sha1:sMwRfygJxWDxWt5Jk03RGh0UVMY=
Bytes: 4241

On 2024-06-10 15:33:23 +0000, olcott said:

> On 6/10/2024 4:59 AM, Mikko wrote:
>> On 2024-06-10 08:35:09 +0000, joes said:
>> 
>>> Am Sun, 09 Jun 2024 22:54:52 -0500 schrieb olcott:
>>>> On 5/29/2021 2:26 PM, olcott wrote:
>>>> https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ
>>>> 
>>>> THE ONLY POSSIBLE WAY for D simulated by H to have the same behavior as
>>>> the directly executed D(D) is for the instructions of D to be
>>>> incorrectly simulated by H (details provided below).
>>>> 
>>>> _D()
>>>> [00000cfc](01)  55                      push ebp
>>>> [00000cfd](02)  8bec                    mov ebp,esp
>>>> [00000cff](03)  8b4508                  mov eax,[ebp+08]
>>>> [00000d02](01)  50                      push eax       ; push D
>>>> [00000d03](03)  8b4d08                  mov ecx,[ebp+08]
>>>> [00000d06](01)  51                      push ecx       ; push D
>>>> [00000d07](05)  e800feffff              call 00000b0c  ; call H
>>>> [00000d0c](03)  83c408                  add esp,+08
>>>> [00000d0f](02)  85c0                    test eax,eax
>>>> [00000d11](02)  7404                    jz 00000d17
>>>> [00000d13](02)  33c0                    xor eax,eax
>>>> [00000d15](02)  eb05                    jmp 00000d1c
>>>> [00000d17](05)  b801000000              mov eax,00000001
>>>> [00000d1c](01)  5d                      pop ebp
>>>> [00000d1d](01)  c3                      ret Size in
>>>> bytes:(0034) [00000d1d]
>>>> 
>>>> In order for D simulated by H to have the same behavior as the directly
>>>> executed D(D) H must ignore the instruction at machine address
>>>> [00000d07]. *That is an incorrect simulation of D*
>>> I don't understand. Does D(D) ignore the call to H(D,D)?
>>> 
>>>> H does not ignore that instruction and simulates itself simulating D.
>>>> The simulated H outputs its own execution trace of D.
>> 
>> What instructions does H use to output that trace and how those
> 
> I don't remember it has been two years.
> I am looking into this again.
> 
>> instructions are simulated when H is simulated?
>> 
> 
> They are simulated by
> u32  DebugStep(Registers* master_state,
>                 Registers* slave_state, Decoded_Line_Of_Code* decoded)
>                 { return 0; }
> 
> This depends on libx86emu.
> 
>> And why does H output any traces? That is not required by its
> 
> The traces are output so that people can directly see the
> same infinite recursion behavior pattern that H sees and
> thus know that H really is required to abort ts simulation.

Looks like they don't serve that purpose. Perhaps you should
change something.

>> specification or purpose. If traces are needed for some other
>> purpose it would be better to let the execution environment
>> make the traces. If your normal execution environment cannot
>> make them then use ontother one that can, e.g. a simulator.

-- 
Mikko