On 8/16/25 10:40 AM, olcott wrote:

On 8/16/2025 8:13 AM, dbush wrote:

On 8/16/2025 8:36 AM, olcott wrote:

On 8/15/2025 11:35 PM, Richard Heathfield wrote:

On 16/08/2025 04:46, olcott wrote:

On 8/15/2025 10:44 PM, Richard Heathfield wrote:

On 16/08/2025 04:01, olcott wrote:

All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:

No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD promptly
halts.

As Kaz indicated these are different DD's.

As C indicates, they're the same DD. I've already posted the
relevant citations from ISO/IEC 9899.

HHH1 and HHH are identical except for their names per diff.
HHH(DDD) and HHH1(DDD) have provable different execution traces

False, as you have admitted on the record (see below):


On 8/16/2025 12:16 AM, dbush wrote:

On 8/15/2025 11:58 PM, olcott wrote:

On 8/15/2025 10:50 PM, dbush wrote:

On 8/15/2025 11:41 PM, olcott wrote:

On 8/15/2025 3:53 PM, dbush wrote:

And how *exactly* does the emulation of the first instruction of
HHH differ when HHH emulates it compared to when HHH1 emulates it? >>  >>>>>

;
When HHH emulates the same sequence again and
HHH1 never emulates the same sequence again.
;

;
False.  As shown by the side by side trace posted previously, the
emulations performed by HHH1 and HHH are exactly the same up the
point that HHH aborts.
;

;
I conclusively prove beyond all doubt otherwise.

;
You've claimed, nothing more.
;

;
So I'll ask once more: which instruction is emulated differently and >>  >>> how?
;
A valid answer will be of the form: "The divergence happens on the
Nth instruction which is I, where the processor does X when HHH
simulates instruction I and the processor does Y when HHH1 simulates >>  >>> instruction I."
;
Failure to give a valid answer in your next reply or within one hour >>  >>> of your next post in this newsgroup will be taken as your official
on-the- record admission that the emulation performed by HHH1 and

HHH

are in fact THE SAME up to the point that HHH aborts

;

;
Let the record show that Peter Olcott failed to explain which
instruction HHH emulated differently from HHH1 and how.  So, as per

the

above criteria:
;
Let The Record Show
;
That Peter Olcott
;
Has *officially* admitted
;
That the emulations performed by HHH and HHH1 are in fact THE SAME

up to

the point that HHH aborts and therefore that there is NO divergence.

*You are a liar* You have been told this too many
times for it to be an honest mistake.

As proven below HHH(DDD) emulates the sequence of DDD
instructions twice and HHH1(DDD) emulates the sequence
of DDD instructions once.

But it isn't a correct simulation.

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH
[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1
[000021b0] 83c404         add esp,+04
[000021b3] 33c0           xor eax,eax
[000021b5] 5d             pop ebp
[000021b6] c3             ret
Size in bytes:(0020) [000021b6]

 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  ========== ============= [000021a3][0010382d][00000000] 55         push ebp      ; main() [000021a4][0010382d][00000000] 8bec       mov ebp,esp   ; main() [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD [000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138d9 [00002183][001138c9][001138cd] 55         push ebp      ; DDD of HHH1
[00002184][001138c9][001138cd] 8bec       mov ebp,esp   ; DDD of HHH1 [00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9

This is NOT a correct x86 simulation of a call HHH instruciton.

Thus BOTH of them are not doing a correct simulation at the x86 level

Begin Local Halt Decider Simulation   Execution Trace Stored at:15e301 [00002183][0015e2f1][0015e2f5] 55         push ebp      ; DDD of HHH[0]
[00002184][0015e2f1][0015e2f5] 8bec       mov ebp,esp   ; DDD of HHH[0]
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD [0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21

*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*

[00002183][001a8d19][001a8d1d] 55         push ebp      ; DDD of HHH[1]
[00002184][001a8d19][001a8d1d] 8bec       mov ebp,esp   ; DDD of HHH[1]
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

And this is an error at the abstract level of simulation, as HHH is a conditional simulator, and, for the version you are defining, WILL abort
its simulation if we look at the correct simulation that goes on after
this point (which this HHH just can't do)

Thus, there is NO infinte recursion, only finite, and you are shown to
be just a stupid liarl

[00002190][001138c9][001138cd] 83c404     add esp,+04 ; DDD of HHH1 [00002193][001138cd][000015a8] 5d         pop ebp     ; DDD of HHH1
[00002194][001138d1][0003a980] c3         ret         ; DDD of HHH1
[000021b0][0010382d][00000000] 83c404     add esp,+04 ; main() [000021b3][0010382d][00000000] 33c0       xor eax,eax ; main() [000021b5][00103831][00000018] 5d         pop ebp     ; main() [000021b6][00103835][00000000] c3         ret         ; main()
Number of Instructions Executed(352831) == 5266 Pages

So, all you are doing it proving the base facts that show that you your
claims are lies.

Your claim "correct x86 emulation" is NOT a correct emulation, as you
have been told but ignore, because you are too stupid to understand such
a simple concept.

Since you don't HAVE a correct simulation of the input, you can't derive anything from somehting that doesn't exist.

Sorry, you are just proving that you are just a stupid ignorant
pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)