Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: DD specifies non-terminating behavior to HHH ---USPTO
 Incorporation by reference --- despicable dishonesty
Date: Sun, 23 Feb 2025 23:44:18 -0500
Organization: A noiseless patient Spider
Lines: 131
Message-ID: <vpgtf1$tdkf$2@dont-email.me>
References: <vo6420$3mpmf$1@dont-email.me> <vote0u$nf28$1@dont-email.me>
 <3b8a5f4be53047b2a6c03f9678d0253e137d3c40@i2pn2.org>
 <votn1l$pb7c$1@dont-email.me>
 <5cd9bc55c484f10efd7818ecadf169a11fcc58e1@i2pn2.org>
 <votq5o$ppgs$1@dont-email.me> <vouu57$12hqt$3@dont-email.me>
 <vp1jkg$1kstl$1@dont-email.me> <vp1qp1$1m05h$2@dont-email.me>
 <vp46l6$26r1n$1@dont-email.me> <vp5t55$2gt2s$1@dont-email.me>
 <vp6pmb$2opvi$1@dont-email.me> <vp8700$30tdq$1@dont-email.me>
 <vp8att$1cec$1@news.muc.de> <vp8h5n$32ifn$1@dont-email.me>
 <39c74e68a47f768d432f5528493b6db9b946ea83@i2pn2.org>
 <vpcvc7$irt$6@dont-email.me>
 <65d495d5d1da61e1bff8426a80fb7d6b046a7f71@i2pn2.org>
 <vpdr2j$6bqs$2@dont-email.me> <vpe1s3$7gnd$2@dont-email.me>
 <vpfm3h$j7qb$2@dont-email.me>
 <c267c2607cac84a040ecd629ef62cb11561f64e4@i2pn2.org>
 <vpgpfe$p9vl$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Feb 2025 05:44:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2824c1e0c122bd29eea4e0491b46b547";
	logging-data="964239"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX192I59I8dZmALByfDR4BqeG"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gJbVi0xuFcyYfIDf/BgZ/cdBoJM=
Content-Language: en-US
In-Reply-To: <vpgpfe$p9vl$2@dont-email.me>
Bytes: 6780

On 2/23/2025 10:36 PM, olcott wrote:
> On 2/23/2025 8:50 PM, Richard Damon wrote:
>> On 2/23/25 12:32 PM, olcott wrote:
>>> On 2/22/2025 8:41 PM, dbush wrote:
>>>> On 2/22/2025 7:45 PM, olcott wrote:
>>>>> On 2/22/2025 6:02 PM, Richard Damon wrote:
>>>>>> On 2/22/25 11:52 AM, olcott wrote:
>>>>>>> On 2/22/2025 5:05 AM, joes wrote:
>>>>>>>> Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:
>>>>>>>>> On 2/20/2025 4:38 PM, Alan Mackenzie wrote:
>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 2/20/2025 2:38 AM, Mikko wrote:
>>>>>>>>>>>> On 2025-02-20 00:31:33 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>>>> I have given everyone here all of the complete source code 
>>>>>>>>>>>>> for a few
>>>>>>>>>>>>> years
>>>>>>>>>>>> True but irrelevant. OP did not specify that HHH means that
>>>>>>>>>>>> particular code.
>>>>>>>>>>> Every post that I have been talking about for two or more 
>>>>>>>>>>> years has
>>>>>>>>>>> referred to variations of that same code.
>>>>>>>>>> Yes.  It would be a relief if you could move on to posting 
>>>>>>>>>> something
>>>>>>>>>> new and fresh.
>>>>>>>>> As soon as people fully address rather than endlessly dodge my key
>>>>>>>>> points I will be done.
>>>>>>>> Honestly, you're gonna die first, one way or the other.
>>>>>>>>
>>>>>>>>> Let's start with a root point.
>>>>>>>>> All of the other points validate this root point.
>>>>>>>>> *Simulating termination analyzer HHH correctly determines*
>>>>>>>>> *the non-halt status of DD*
>>>>>>>> Since DD halts, that's dead in the water.
>>>>>>>>
>>>>>>>
>>>>>>> Despicably intentionally dishonest attempts at the straw-man
>>>>>>> deception aside:
>>>>>>>
>>>>>>> DD correctly simulated by HHH cannot possibly terminate
>>>>>>> normally by reaching its own "return" instruction.
>>>>>>>
>>>>>>
>>>>>> Only because that statement is based on a false premise.
>>>>>>
>>>>>> Since HHH doesn't correctly simulate its input, your statement is 
>>>>>> just a fabrication of your imagination.
>>>>>
>>>>> *Correct simulation means emulates the machine code as specified*
>>>>> It cannot mean imagining a different sequence than the one that the 
>>>>> machine code specifies. That most people here are clueless about
>>>>> x86 machine code is far less than no rebuttal at all.
>>>>>
>>>>> _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 DD emulated by HHH calls HHH(DD) this call cannot
>>>>> possibly return to the emulator, conclusively proving
>>>>> that
>>>>>
>>>>> DD correctly simulated by HHH cannot possibly terminate
>>>>> normally by reaching its own "return" instruction.
>>>>>
>>>>> Assuming that it does return is simply stupid.
>>>>>
>>>>>
>>>>
>>>> Similarly, when no_numbers_greater_than_10 emulated by F calls F(0) 
>>>> this call cannot possibly return to the emulator, conclusively 
>>>> proving that
>>>
>>> Not true. The stack eventually unwinds after ten emulations.
>>
>> Just like a CORRECT emulation of DD would if the HHH doing the 
>> emulation didn't abort (but doing it by the hypothetical of NOT 
>> changing the HHH that DD calls, since that must be the original HHH).
>>
>> Your problem is you have lied to yourself about what is a "correct 
>> emulation" 
> 
> In other words you "believe" that the call from DD to HHH(DD)
> returns when the above DD is emulated by HHH.
> 
> This is proven to be counter-factual by anyone that understands
> the above code.
> 

int no_numbers_greater_than_10();

int F(uintptr_t p)
{
   uintptr_t ptr = (uintptr_t)no_numbers_greater_than_10;
   uintptr_t i = p ^ ptr;
   if (i > 10)
     return 0;
   else
     return F((i+1) ^ ptr);
}

int no_numbers_greater_than_10()
{
   return F((uintptr_t)no_numbers_greater_than_10);
}

int main()
{
   F((uintptr_t)no_numbers_greater_than_10);
   return 0;
}

In other words you "believe" that the call from 
no_numbers_greater_than_10 to F(no_numbers_greater_than_10)
returns when the above no_numbers_greater_than_10 is emulated by F.

This is proven to be counter-factual by anyone that understands
the above code.