Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: People are still trying to get away with disagreeing with the semantics of the x86 language
Date: Sun, 30 Jun 2024 11:50:46 +0300
Organization: -
Lines: 125
Message-ID: <v5r696$enkl$1@dont-email.me>
References: <v5pbjf$55h$1@dont-email.me> <v5pdmk$1gd9e$1@i2pn2.org> <v5pfj9$adt$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 10:50:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="edf92710cff98efa55bbf9e0df377222";
	logging-data="482965"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19M2tdJaiXN5METTK5exlxT"
User-Agent: Unison/2.2
Cancel-Lock: sha1:Yiqex/S3fseHLeRL93kfn4FmkPo=
Bytes: 5576

On 2024-06-29 17:17:29 +0000, olcott said:

> On 6/29/2024 11:45 AM, Richard Damon wrote:
>> On 6/29/24 12:09 PM, olcott wrote:
>>> 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.
>> 
>> Nope, we are not disagreeing with the semantics of the x86 language, we 
>> are disagreeing with your misunderstanding of how it works.
>> 
>>> 
>>> 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.
>> 
>> No the x86 language "knows" NOTHING about H0 being a x86 emulator. It 
>> is just a function that maybe happens to be a partial x86 emulator, but 
>> that is NOT a fundamental result of it being H0.
>> 
>>> 
>>> 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.
>> 
>> It is construed as non-halting BECAUSE it has been shown that your H0 
>> *WILL* terminate its PARTIAL emulation of the code it is emulating and 
>> returning.
>> 
>>> 
>>> 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.
>> 
>> Right, so H0 is REQUIRED to return, and thus if the termination 
>> analyser knows that H0 is a termination analyzer it knows that the call 
>> to H0 MUST return, and thus DDD must be a terminating program.
>> 
>> An H0 that doesn't know this, and can't figure out that H0 will return, 
>> but just keeps emulating H0 emulating its input will just fail to meet 
>> its own requirement to return.
>> 
>>> 
>>> <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>
>> 
>> Right, and the only definition Professor Sipser uses for "Correct 
>> Simulation" is a simulation that EXACTLY REPRODUCES the behavior of the 
>> directly executed program represented by the input. Your H doesn't do 
>> that, nor correctly predicts the behavior of such a simulation of the 
>> input (since that behavior is to halt) so it can never proper avail 
>> itself of the second paragraph, so does so erroneously getting the 
>> wrong answer.
>> 
>>> 
>>> 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.
>> 
>> Except that the "N Steps of DDD correctly emulated" is NOT the 
>> definition of the "behavior" of the input DDD.
>> 
>> "inputs" Do not have "behavoir", that is a property of a program, so 
>> the input only "represents" that program, in this case the program DDD.
>> 
> 
> *According to the professor Sipser approved criteria YES IT IS*

It is not a good idea to speculate about other peoples opinions.
Better to stick to the topic specified by OP.

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


-- 
Mikko