Re: The actual code of HHH

On 2/28/25 7:41 PM, olcott wrote:

On 2/28/2025 2:36 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 22:42 schreef olcott:

>
It is flat out dishonest to change the subject away
from DD emulated by HHH.
>

>
It is flat out incorrect to suggest that this DD is a different one. There is only one finite string, describing only one behaviour.

 It is a verified fact that the directly executed DD has a
different execution trace than DD emulated by HHH.

Then VERIFY IT,
What is the first instruction in the execution trace of the directly executed DD differs from that in the emulated by HHH.
This has been asked for before and never actually answered, proving that you claim is just a blantant lie. At best you try to argue that HHH is allowed to incorrect emulate instuctions and the difference is that HHH get to assume incorrect behavior for HHH.
Sorry, your "logic" is just built on lies.

 People try to get away with saying this is wrong are dumbfounded
when I challenge them to provide the correct execution trace
of DD emulated by HHH.

Execpt you don't, because you edit out parts you don't loke, and add in things that don't happen,

 _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]
 It is perfectly fine to say that you just don't understand
that. What is terribly wrong is for you to know that you
don't understand that and claim that I am incorrect.

So, why don't you do that?
Your error has been pointed out, and you just ignore it, because you don't believe in facts. That just proves that you are just a stupid path

 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.

And thus you prove that you arguement is built on the belief in a Truth Fairy that can make a statement true that isn't. At 0000213c isn't a correct emulator, but just a partial one that will abort its emulation and return. We know that as your arguement has it do that. Thus, your argument is based on LIES.

 When we add the additional complexity that HHH also
aborts this sequence at some point then every level
of recursive emulation stops. This does not enable
any DD to ever reach its "ret" instruction.

Which makes it NOT a correct emulation, and breaks the conclusion you made about DD.

 If this is beyond your technical competence
THAT DOES NOT MAKE ME WRONG
 

That you dont understand how programs works, does.
Your logic is just built on lies.