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: People are still trying to get away with disagreeing with the
 semantics of the x86 language
Date: Sun, 30 Jun 2024 19:53:01 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v5sr4t$1kfbq$1@i2pn2.org>
References: <v5pbjf$55h$1@dont-email.me> <v5r5q9$ekvf$1@dont-email.me>
 <v5s40h$jvgt$1@dont-email.me> <v5sbpt$1kfbr$2@i2pn2.org>
 <v5sjsa$msl0$1@dont-email.me> <v5skc9$1kfbr$7@i2pn2.org>
 <v5smuk$n7a2$1@dont-email.me> <v5sorr$1kfbr$10@i2pn2.org>
 <v5sp4v$nnko$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 30 Jun 2024 23:53:01 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1719674"; 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: <v5sp4v$nnko$1@dont-email.me>
Bytes: 9749
Lines: 203

On 6/30/24 7:18 PM, olcott wrote:
> On 6/30/2024 6:14 PM, Richard Damon wrote:
>> On 6/30/24 6:41 PM, olcott wrote:
>>> On 6/30/2024 4:57 PM, Richard Damon wrote:
>>>> On 6/30/24 5:48 PM, olcott wrote:
>>>>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>>>>> On 6/30/24 1:18 PM, olcott wrote:
>>>>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>>>>
>>>>>>>>> People are still trying to get away with disagreeing with
>>>>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>>>>
>>>>>>>>> typedef void (*ptr)();
>>>>>>>>> int H0(ptr P);
>>>>>>>>>
>>>>>>>>> void Infinite_Loop()
>>>>>>>>> {
>>>>>>>>>    HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> void Infinite_Recursion()
>>>>>>>>> {
>>>>>>>>>    Infinite_Recursion();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>>    H0(DDD);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    H0(Infinite_Loop);
>>>>>>>>>    H0(Infinite_Recursion);
>>>>>>>>>    H0(DDD);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Every C programmer that knows what an x86 emulator is knows
>>>>>>>>> that when H0 emulates the machine language of Infinite_Loop,
>>>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations
>>>>>>>>> so that itself can terminate normally.
>>>>>>>>>
>>>>>>>>> When this is construed as non-halting criteria then simulating
>>>>>>>>> termination analyzer H0 is correct to reject these inputs as
>>>>>>>>> non-halting by returning 0 to its caller.
>>>>>>>>>
>>>>>>>>> Simulating termination analyzers must report on the behavior
>>>>>>>>> that their finite string input specifies thus H0 must report
>>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>>>>> simulation.
>>>>>>>>>
>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 
>>>>>>>>> 10/13/2022>
>>>>>>>>>      If simulating halt decider H correctly simulates its input D
>>>>>>>>>      until H correctly determines that its simulated D would never
>>>>>>>>>      stop running unless aborted then
>>>>>>>>>
>>>>>>>>>      H can abort its simulation of D and correctly report that D
>>>>>>>>>      specifies a non-halting sequence of configurations.
>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 
>>>>>>>>> 10/13/2022>
>>>>>>>>>
>>>>>>>>> People are trying to get away with disagreeing with the semantics
>>>>>>>>> of the x86 language by disagreeing that
>>>>>>>>>
>>>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>>>>> emulated by any pure function x86 emulator HHH cannot possibly
>>>>>>>>> return.
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [00002172] 55               push ebp      ; housekeeping
>>>>>>>>> [00002173] 8bec             mov ebp,esp   ; housekeeping
>>>>>>>>> [00002175] 6872210000       push 00002172 ; push DDD
>>>>>>>>> [0000217a] e853f4ffff       call 000015d2 ; call HHH(DDD)
>>>>>>>>> [0000217f] 83c404           add esp,+04
>>>>>>>>> [00002182] 5d               pop ebp
>>>>>>>>> [00002183] c3               ret
>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>>>>
>>>>>>>> Nothing above is or points to any evdence about the alleged 
>>>>>>>> disagreement.
>>>>>>>>
>>>>>>>
>>>>>>> Of course not. I only said the actual truth.
>>>>>>>
>>>>>>> Richard just said that he affirms that when DDD correctly
>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>>>>> though the semantics of the x86 language disagrees.
>>>>>>
>>>>>> What in the sematics of the x86 language, which INCLUDES that ever 
>>>>>> instruction WILL be followed by the next instruction, says that 
>>>>>> the HHH that is calld by DDD won't eventually return.
>>>>>>
>>>>>> Since you assert that HHH(DDD) called by main returns, then by 
>>>>>> your requreement that HHH be a "pure function" ALL copies of it 
>>>>>> will do the same thing.
>>>>>>
>>>>>> Yes, the EMULATION of HHH by HHH, but that can not be the 
>>>>>> "behavior of the input" as that "behavior" depends on more than 
>>>>>> just the input.
>>>>>>
>>>>>
>>>>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>>>>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>>>>
>>>>
>>>> And then it doesn't correct emulate the input, and thus is a LIAR.
>>>>
>>>
>>> You already know that you are the liar here and are
>>> lying about not knowing this.
>>>
>>> _DDD()
>>> [00002172] 55               push ebp      ; housekeeping
>>> [00002173] 8bec             mov ebp,esp   ; housekeeping
>>> [00002175] 6872210000       push 00002172 ; push DDD
>>> [0000217a] e853f4ffff       call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404           add esp,+04
>>> [00002182] 5d               pop ebp
>>> [00002183] c3               ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> The call from DDD to HHH(DDD) when N steps of DDD are
>>> correctly emulated by any pure function x86 emulator
>>> HHH at machine address 0000217a cannot possibly return.
>>>
>>
>> The problem is that the N steps emulated by HHH are not, and CAN NOT 
>> be the "behavior of the input", 
> They need not be the FULL behavior of the input.
> 
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until
>      H correctly simulates its input D until

And that can NOT be the "Behavior of the Input" as it depends on more 
that just the input.


Your question is just like asking what is two plus ____?

> 
>      H correctly determines that its simulated D would never
========== REMAINDER OF ARTICLE TRUNCATED ==========