Deutsch   English   Français   Italiano  
<v41tj5$2ll6e$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
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 10:32:53 -0500
Organization: A noiseless patient Spider
Lines: 141
Message-ID: <v41tj5$2ll6e$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 08 Jun 2024 17:32:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="99ea1b6838dd1404bad406fc122dbf0f";
	logging-data="2806990"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX186t2Anh2qyF9SFOjKJURJW"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:yeJTkxwE6zeZPu/aIRByyRlBN9c=
Content-Language: en-US
In-Reply-To: <v41sjf$3cg3s$8@i2pn2.org>
Bytes: 6888

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.

> 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].

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

The underlying details of one HH are irrelevant when I reference
an infinite set:

{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}


> 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.

> 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.

> 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.

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

We are only focusing on this one thread and zero deflection
will be tolerated.

>>
>> 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.
> 

When you proved to break out of your "stuck in rebuttal mode"
nonsense and talked about closure I backed off this requirement
for a while.

*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.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer