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 11:15:59 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v41sjf$3cg3s$8@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 8 Jun 2024 15:15:59 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3555452"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v41s4e$2l7o9$2@dont-email.me>
Bytes: 5561
Lines: 97

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)

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.

By your code, the simulator will "Debug Step" those instructions.

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.

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.

So, your claim of what happens just shows you don't understand what the 
program you are using actually is doing.

That might explain why the trace you posted the other day wasn't 
actually the trace you claimed it was.

> 
> This is the only post that I will reply to you on.
> I need you to stay focused on this one single point
> until you understand it.

Is that a promise? I think you will break it.

> 
> *Even Ben admits that H does meet the Sipser criteria*
> 
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>  > I don't think that is the shell game. PO really /has/ an H
>  > (it's trivial to do for this one case) that correctly determines
>  > that P(P) *would* never stop running *unless* aborted.
> 
>