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
Subject: Re: People are still trying to get away with disagreeing with the
 semantics of the x86 language
Date: Thu, 4 Jul 2024 11:25:20 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <2aa87b5affde40f3265e6857a3c44c7f91fe0b0b@i2pn2.org>
References: <v5pbjf$55h$1@dont-email.me> <v5r5q9$ekvf$1@dont-email.me>
 <v5s40h$jvgt$1@dont-email.me> <v5tgvj$utcb$1@dont-email.me>
 <v5u8c9$12udb$1@dont-email.me> <v608ft$1hqo6$1@dont-email.me>
 <v61hoo$1og2o$1@dont-email.me> <v61k27$1oec9$3@dont-email.me>
 <v61li2$1p1uo$2@dont-email.me> <v63205$23ohl$1@dont-email.me>
 <v63j94$26loi$4@dont-email.me>
 <db9212dd66972657132755b66b6c473167119450@i2pn2.org>
 <v63o75$27nhv$2@dont-email.me>
 <6ca7c213b3ec5e20ae45c951ea48fbffcf5aae91@i2pn2.org>
 <v665in$2oun1$7@dont-email.me>
 <b36744609d2139c1264ecb8d6e348c1f4b68787e@i2pn2.org>
 <v668q2$2pc84$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 4 Jul 2024 15:25:20 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2132707"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v668q2$2pc84$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 7432
Lines: 128

On 7/4/24 9:41 AM, olcott wrote:
> On 7/4/2024 8:26 AM, joes wrote:
>> Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:
>>> On 7/4/2024 5:15 AM, joes wrote:
>>>> Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
>>>>> On 7/3/2024 9:39 AM, joes wrote:
>>>>>> Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
>>>>>>> On 7/3/2024 3:26 AM, Fred. Zwarts wrote:
>>>>>>>> Op 02.jul.2024 om 21:48 schreef olcott:
>>>>>>>>> On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
>>>>>>>>>> Op 02.jul.2024 om 20:43 schreef olcott:
>>>>>>>>>>> On 7/2/2024 1:59 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-07-01 12:44:57 +0000, olcott said:
>>>>>>>>>>>>> On 7/1/2024 1:05 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-06-30 17:18:09 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>> Which semantics?
>>>> I repeat.
>> What x86 semantics say that HHH can’t return?
>>
>>>>>>> DDD correctly emulated by HHH calls an emulated HHH(DDD) that
>>>>>>> emulates DDD that calls an emulated HHH(DDD)
>>>>>>> in a cycle that cannot end unless aborted.
>>>>>> But HHH aborts, so the cycle does end.
>>>>> As long as it is impossible for DDD correctly emulated by HHH to reach
>>>>> its own ret instruction then DDD never halts even when its stops
>>>>> running because its emulation was aborted.
>>>> HHH halts by definition. Why can’t DDD?
>>> By definition DDD calls its simulator.
>> Yes, and nothing else. So when HHH returns, so does DDD.
>>
> 
> You simply lack sufficient technical competence of these things
> *Machine address 00002174 of DDD is never reached*
> I am using an x86 emulator with decades of development effort.
> 
> _DDD()
> [00002163] 55         push ebp
> [00002164] 8bec       mov ebp,esp
> [00002166] 6863210000 push 00002163 ; push DDD
> [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
> [00002170] 83c404     add esp,+04
> [00002173] 5d         pop ebp
> [00002174] c3         ret
> Size in bytes:(0018) [00002174]
> 
> _main()
> [00002183] 55         push ebp
> [00002184] 8bec       mov ebp,esp
> [00002186] 6863210000 push 00002163
> [0000218b] e833f4ffff call 000015c3
> [00002190] 83c404     add esp,+04
> [00002193] 33c0       xor eax,eax
> [00002195] 5d         pop ebp
> [00002196] c3         ret
> Size in bytes:(0020) [00002196]
> 
>   machine   stack     stack     machine    assembly
>   address   address   data      code       language
>   ========  ========  ========  =========  =============
> [00002183][001037dd][00000000] 55         push ebp
> [00002184][001037dd][00000000] 8bec       mov ebp,esp
> [00002186][001037d9][00002163] 6863210000 push 00002163
> [0000218b][001037d5][00002190] e833f4ffff call 000015c3
> New slave_stack at:103881 ; *create a different process context*
> Begin Local Halt Decider Simulation   Execution Trace Stored at:113889

Why does main calling HHH create a new "process context" that isn't what 
CALL Instructions do.

SO, you simulation is clearly not correct, or not correctly interpreted.

The trace of the program should have continued showing the PROGRAMs 
execution path.

Yes, at some point that HHH will creeate a virtual process context to 
simulate that you show below, but that means that the below trace is no 
longer a trace of main calling HHH, but of the simulation of HHH.



> [00002163][00113879][0011387d] 55         push ebp
> [00002164][00113879][0011387d] 8bec       mov ebp,esp
> [00002166][00113875][00002163] 6863210000 push 00002163 ; push DDD
> [0000216b][00113871][00002170] e853f4ffff call 000015c3 ; call HHH(DDD)
> New slave_stack at:14e2a9 ; *create a different process context*

And calling HHH(DDD) doesn't create a new process context either, it 
calls the function HHH which is what should be traced here.

Yes, your simulated HHH will create within itself a new virtual process 
context and this is now a THIRD DISTINCT SIMULATION which is INCORRECTLY 
shown as part of the simulation of the above two different simulations.

THAT IS AN ERROR.

> [00002163][0015e2a1][0015e2a5] 55         push ebp
> [00002164][0015e2a1][0015e2a5] 8bec       mov ebp,esp
> [00002166][0015e29d][00002163] 6863210000 push 00002163 ; push DDD
> [0000216b][0015e299][00002170] e853f4ffff call 000015c3 ; call HHH(DDD)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> 
> [00002190][001037dd][00000000] 83c404     add esp,+04
> [00002193][001037dd][00000000] 33c0       xor eax,eax
> [00002195][001037e1][00000018] 5d         pop ebp
> [00002196][001037e5][00000000] c3         ret
> Number of Instructions Executed(10066) == 150 Pages
> 
> 

So, by playing the shell games and mixing up three different program 
context that exists you confused yourself in beleiving your own lies.

The simulation of the second program context was shown to be terminated, 
but that same program context, when fully simulated will show the same 
sort of behavior, of it aborting its simulation of the third program 
context, and returning, and thus the CORRECT behavior of the second 
context is that it will be finite and return.

Your problem is you don't understand that simulation doesn't define the 
behavior of the input, it reveals that part of it that it does. The full 
behavior of the input is defined by what the program it represents does, 
which is what a COMPLETE simulation of it will show.

This is just more of your confusion of Truth and Knowledge which has 
made your logic system broken.