Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: How Partial Simulations correctly determine non-halting ---Should
 I quit Richard at this point?
Date: Sat, 8 Jun 2024 12:03:18 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v41vc6$3cg3t$26@i2pn2.org>
References: <v3j20v$3gm10$2@dont-email.me>
 <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <87h6eamkgf.fsf@bsb.me.uk> <v3kcdj$3stk9$1@dont-email.me>
 <v3l7uo$13cp$8@dont-email.me> <v3lcat$228t$3@dont-email.me>
 <v3mq9j$chc3$1@dont-email.me> <v3mrli$chc4$1@dont-email.me>
 <_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <v3nkqr$h7f9$3@dont-email.me> <v3p4ka$sk6h$1@dont-email.me>
 <v3pp7p$v133$8@dont-email.me> <v3s27e$1f9kd$1@dont-email.me>
 <v3sf1n$1gra7$11@dont-email.me> <v3sjo9$1ialb$1@dont-email.me>
 <v3skoo$1iedv$1@dont-email.me> <v3u9ej$1v7rn$1@dont-email.me>
 <v3v6i7$23l33$1@dont-email.me> <v3ve38$259cg$1@dont-email.me>
 <v3vf0b$24orn$4@dont-email.me> <v40u4u$2gi7t$1@dont-email.me>
 <v41k6l$2jqdk$8@dont-email.me> <v41l89$3cg3t$12@i2pn2.org>
 <v41nei$2kanc$8@dont-email.me> <v41oo8$3cg3t$22@i2pn2.org>
 <v41pbc$2kanc$15@dont-email.me> <v41raj$3cg3t$25@i2pn2.org>
 <v41s4e$2l7o9$2@dont-email.me> <v41sjf$3cg3s$8@i2pn2.org>
 <v41tj5$2ll6e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 8 Jun 2024 16:03:18 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3555453"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v41tj5$2ll6e$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 9209
Lines: 210

On 6/8/24 11:32 AM, olcott wrote:
> On 6/8/2024 10:15 AM, Richard Damon wrote:
>> On 6/8/24 11:07 AM, olcott wrote:
>>> On 6/8/2024 9:54 AM, Richard Damon wrote:
>>>> On 6/8/24 10:20 AM, olcott wrote:
>>>>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>>>>>>
>>>>>> I HAVE pointed out what is missing, ANY set of truth-perserving 
>>>>>> operations from the accepted facts (which will of course need to 
>>>>>> name the fact they are working from) to your conclusion.
>>>>>
>>>>> The accepted facts are here
>>>>> (a) The x86 language
>>>>> (b) The notion of an x86 emulator
>>>>>
>>>>> {The proof that No DDD correctly emulated by any x86
>>>>>   emulator H can possibly reach its own [00001df6] instruction}
>>>>
>>>> So, how do you show this claim?
>>>>
>>>> Do you have a tracing of the full INFINITE SET of possible Hs?
>>>>
>>>>>
>>>>> Is the set of possible execution traces of DDD correctly
>>>>> emulated by x86 emulator HH on the basis of the above
>>>>> accepted facts.
>>>>>
>>>>> Maybe you are just clueless about these technical details
>>>>> are are trying to hide this with pure bluster.
>>>>>
>>>>> _DDD()
>>>>> [00001de2] 55         push ebp
>>>>> [00001de3] 8bec       mov ebp,esp
>>>>> [00001de5] 8b4508     mov eax,[ebp+08]
>>>>> [00001de8] 50         push eax         ; push DD
>>>>> [00001de9] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001dec] 51         push ecx         ; push DD
>>>>> [00001ded] e890f5ffff call 00001382    ; call HH
>>>>> [00001df2] 83c408     add esp,+08
>>>>> [00001df5] 5d         pop ebp
>>>>> [00001df6] c3         ret
>>>>> Size in bytes:(0021) [00001df6]
>>>>>
>>>>> You keep disagreeing with the fact that DDD correctly
>>>>> emulated by x86 emulator HH only has one single correct
>>>>> execution trace of repeating the fist seven lines until
>>>>> out-of-memory error.
>>>>>
>>>>
>>>> But that is an INCORRECT trace per your definition,
>>>>
>>>> The call HH instruction MUST be simulated into HH because that IS 
>>>> the behavior of the x86 instruction.
>>>
>>> Did I ever say that it is not?
>>> For the above DDD correctly emulated by x86 emulator HH
>>> the first seven instructions of DD keep repeating because
>>> DDD keeps calling HH(DDD,DDD) to emulate itself again and
>>> again until HH/DDD hits out-of-memory exception.
>>
>> So the x86 emulation of the code must go into HH(DDD,DDD)
>>
> 
> It is pretty stupid to assume otherwise when HH is
> stipulated to be an x86 emulator.

Right, so why did you say otherwise?


> 
>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get to 
>> the sequence of instrucitions starting at 00001DE2, as the code will 
>> never jump there to just execute it.
>>
> 
> Your are saying that incorrectly DDD correctly emulated by
> x86 emulator HH cannot possibly reach it own machine address
> of [00001df6].

I said nothing about that. You are just serving Herring with Red Sauce 
agian.

The CORRECT simulation of DDD can NEVER get back to the sequence of 
instructions at 00001DE2, as there is never a jump to that address, only 
the emulator starting an emuation of that address, and the correst 
simulation of a simulatore is NOT the code the simulated simulator is 
looking at, but the code of the simulator doing the simulation.

> 
>> By your code, the simulator will "Debug Step" those instructions.
>>
> 
> The underlying details of one HH are irrelevant when I reference
> an infinite set:\

But not for your definition of the simulation.

> 
> {The proof that No DDD correctly emulated by
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> can possibly reach its own [00001df6] instruction}

It seems that by your current analysis, it can't get past the 
instruction at 00001DED as there is nothing to simulate after that.

Remember, your definition said to simulate the instructions in the 
strict order they were reached.

If we don't have the instruction at 00001382, the simulation has to 
stop, as we can't go on.

> 
> 
>> By a pure emulator, that would mean translating the machine code into 
>> the operations it will perform, and then manipulating the virtual 
>> register set being kept by the emulator.
>>
> 
> libx86emu does that.

And if HH is a pure emulator, it need to do it to (or let libx86emu do 
it for it). and HH can't interfear with that process by not following 
each instruction with the instruction that follows it.

So, does the libx86emu keep a seperate logging of the instructions that 
HH is emulating, as would be needed for HH to be able to examine that trace.

The previous trace you posted wasn't the simulation that HH was doing, 
but was a trace of the execution of HH iteself.

It seems that HH doesn't actual have a trace of what it did available 
(or at least you didn't show it).

But then, you always seemed to have gotten the "levels" of simulation 
incorrect.


> 
>> If your "simulation" is ACTUALLY being done using the debug step 
>> hardware of the system (or simulating the actions of that hardware) 
>> then the instruction are executed, but not in sequence as they have 
>> all the steps of the debugger/tracing around them.
>>
> 
> That is not how x86 emulators work.

But it is what "Debug Step" implies.

Or, are you not familiar with that part of the x86 hardware.

> 
>> So, your claim of what happens just shows you don't understand what 
>> the program you are using actually is doing.
>>
> 
> No it shows that you don't know how x86 emulators work.
========== REMAINDER OF ARTICLE TRUNCATED ==========