Deutsch   English   Français   Italiano  
<1806cc1af6c9ab30f55c8c1935a4f20c33daa4db@i2pn2.org>

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

Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: DD emulated by HHH cannot possibly terminate normally --- x86
 code
Date: Sun, 2 Mar 2025 19:42:17 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <1806cc1af6c9ab30f55c8c1935a4f20c33daa4db@i2pn2.org>
References: <vptlfu$3st19$9@dont-email.me> <vpug3h$50td$1@dont-email.me>
 <vq06al$eljf$1@dont-email.me> <vq193s$njjd$1@dont-email.me>
 <vq1q1g$q7t4$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 3 Mar 2025 00:42:18 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2573954"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vq1q1g$q7t4$2@dont-email.me>
Content-Language: en-US
Bytes: 4961
Lines: 95

On 3/2/25 9:30 AM, olcott wrote:
> On 3/2/2025 3:41 AM, Mikko wrote:
>> On 2025-03-01 23:47:30 +0000, olcott said:
>>
>>> On 3/1/2025 2:22 AM, Mikko wrote:
>>>> On 2025-03-01 00:47:58 +0000, olcott said:
>>>>
>>>>> _DD()
>>>>> [00002133] 55         push ebp      ; housekeeping
>>>>> [00002134] 8bec       mov ebp,esp   ; housekeeping
>>>>> [00002136] 51         push ecx      ; make space for local
>>>>> [00002137] 6833210000 push 00002133 ; push DD
>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
>>>>> [00002141] 83c404     add esp,+04
>>>>> [00002144] 8945fc     mov [ebp-04],eax
>>>>> [00002147] 837dfc00   cmp dword [ebp-04],+00
>>>>> [0000214b] 7402       jz 0000214f
>>>>> [0000214d] ebfe       jmp 0000214d
>>>>> [0000214f] 8b45fc     mov eax,[ebp-04]
>>>>> [00002152] 8be5       mov esp,ebp
>>>>> [00002154] 5d         pop ebp
>>>>> [00002155] c3         ret
>>>>> Size in bytes:(0035) [00002155]
>>>>>
>>>>> When we hypothesize that the code at machine address
>>>>> 0000213c is an x86 emulator then we know that DD
>>>>> remains stuck in recursive emulation and cannot possibly
>>>>> reach its own "ret" instruction and terminate normally.
>>>>
>>>> The emulator itself is stuck and cannot return normally but it doesn't
>>>> know it cannot return normally. At some point it runs out of memory
>>>> and terminates normally or abnormally.
>>>>
>>>
>>> Yes you are correct about this sub-step of two steps.
>>>
>>>>> When we add the additional complexity that HHH also
>>>>> aborts this sequence at some point then every level
>>>>> of recursive emulation immediately stops. This does
>>>>> not enable any DD to ever reach its "ret" instruction.
>>>>
>>
>>> When we are answering the question that seems impossible for
>>> anyone here to pay attention to even when repeated hundreds of times:
>>>
>>> Can the above DD correctly emulated by HHH possibly
>>> reach its own "ret" instruction and terminate normally?
>>
>> Already answered.
>>
>>> The answer is dead obviously "no" for everyone that is:
>>> (a) Technically competent
>>>    and
>>> (b) Not deliberately deceptive.
>>
>> Only someone technically incompetent or deliberately deceptive 
>> believes that.
>> If DD correctly emulated by HHH 
> 
> I challenged everyone here to provide the machine address
> by machine address (AKA line by line) execution trace
> of DD correctly emulated by HHH that reaches its own
> "ret" instruction.
> 
> No one made any attempt to do this because they know that
> this would prove that they are stupidly wrong to say that
> my trace is incorrect.
> 
> 

Which since such a thing does not need to exist, is just a bogus claim.

First, since you have exclude the code of HHH from DD, I would challage 
how you possible emulate past the call HHH instruction by *ANY* correct 
emulator that meets the requirement of being a "pure function".

And, when you add that code into DD, then you have locked what HHH is 
defined as, and since your only example does abort, there just isn't an 
HHH that does what you say, proving that HHH can't use that definition 
to help it justify its actions,

Sorry, you are just proving your stupidity.

Note, I *HAVE* posted what you claimed to be the correct simulation of a 
isomorphic program (a real isomophism, not one of your fake onew) that 
show how the correct emulation would go.

So, either you accept that or admit you lied when you posted it,

Either way, you are just admitting to being a liar.


I will also add that your techique of posting widely with limited 
followup, and then reposting just your point widely again, is just more 
evidence that you are nothing but a deliberate fraud, knowingly trying 
to spread false information and lies.