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