Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Fri, 9 May 2025 14:24:41 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <fdd76497f309d42f4d9fa60818dc4b4db0023953@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvh0t2$1b939$1@dont-email.me>
 <vvhap5$1hp80$1@dont-email.me> <vvhf20$1ihs9$1@dont-email.me>
 <vvhfnd$1hvei$3@dont-email.me> <vvil99$1ugd5$1@dont-email.me>
 <vvinvp$1vglb$1@dont-email.me> <vviv75$222r6$1@dont-email.me>
 <vvj1fp$22a62$1@dont-email.me> <vvj2j6$23gk7$1@dont-email.me>
 <as9TP.251456$lZjd.93653@fx05.ams4> <87msbmeo3b.fsf@nosuchdomain.example.com>
 <vvjcge$27753$2@dont-email.me> <87a57mek8r.fsf@nosuchdomain.example.com>
 <vvjgh7$28g5i$4@dont-email.me> <87seled0zy.fsf@nosuchdomain.example.com>
 <vvjobj$28g5i$11@dont-email.me> <87zffmbeyt.fsf@nosuchdomain.example.com>
 <vvk1ha$2ibbd$1@dont-email.me> <87frhebbae.fsf@nosuchdomain.example.com>
 <vvk520$2j56g$1@dont-email.me> <871psyb94z.fsf@nosuchdomain.example.com>
 <vvl5fl$2rl0l$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 9 May 2025 18:34:37 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3837174"; 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: <vvl5fl$2rl0l$3@dont-email.me>

On 5/9/25 11:03 AM, olcott wrote:
> On 5/9/2025 1:17 AM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/9/2025 12:31 AM, Keith Thompson wrote:
>> [...]
>>>> You didn't respond to the above.  I'll ask directly.
>>>> Would I need to understand x86 code to understand your claims?  Yes
>>>> or no.
>>>
>>> It makes it much easier because the state transition graph
>>> of the control flow at the x86 level is unequivocal.
>>
>> What a pity you couldn't have made that clear much sooner.
>>
> 
> Your help on the C part was very useful.
> The x86 part is only needed to understand
> the internals of the simulating termination
> analyzer.
> 
> _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]
> 
> You don't need to understand the first two instructions.
> The next two instructions simply call HHH(DDD) in
> recursive emulation.
> 
> At the x86 machine code level HHH can see that the
> first four instructions of DDD repeats. It sees this
> after it emulates DDD and then emulates itself
> emulating DDD once.
> 
>> As I said, I'm not very familiar with x86 code, and it's
>> absolutely not worth my time and effort to learn it for the sake
>> of understanding your claims.
>>
>> Bye.
>>
> 
> 

And, since you say that is *ALL* of the input, it is CATEGORICALLY 
IMPOSSIBLE for a correct emulator to emulate the instruction, as it is 
missing the details.

Sorry, but you are just showing that youy are so dense that you are 
unable to learn basic definitions in programing.