_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.
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.
_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.
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.
_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.
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.
_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.
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.
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial emulator
that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
On 3/1/2025 6:49 AM, Richard Damon wrote:proves failure of HHH to reach the end of a proven terminating program.
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial emulator
that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial emulator
that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
On 3/1/2025 10:05 AM, Richard Damon wrote:HHH emulating DD fails to reach the 'ret' instruction. We agree. DD, the
On 3/1/25 9:41 AM, olcott wrote:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally
proves non-termination whether aborted or not.
But it DOES terminate
DD emulated by HHH never terminates no matter how many
times you try to get away with the straw-man deception
of referring to anything at all besides
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:
On 3/1/2025 6:49 AM, Richard Damon wrote:proves failure of HHH to reach the end of a proven terminating program.
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally
DD emulated by HHH according to the above x86 machine code of DD
cannot possibly reach its own "ret" instruction and terminate normally
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:
On 3/1/2025 6:49 AM, Richard Damon wrote:proves failure of HHH to reach the end of a proven terminating program.
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally
DD emulated by HHH according to the above x86 machine code of DD
cannot possibly reach its own "ret" instruction and terminate normally
NO MATTER WHAT. Asserting otherwise has always been the straw-man
deception of referring to something other than DD emulated by HHH.
On 3/1/2025 2:16 PM, Fred. Zwarts wrote:In other words, HHH did not terminate the simulation.
Op 01.mrt.2025 om 17:33 schreef olcott:
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:DD emulated by HHH according to the above x86 machine code of DD
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally >>>> proves failure of HHH to reach the end of a proven terminating program. >>>
cannot possibly reach its own "ret" instruction and terminate normally
In other words,
The DD input to HHH unequivocally specifies a
non terminating computation.
On 3/1/2025 2:22 PM, Fred. Zwarts wrote:No, DD calls HHH only once. It is HHH that causes a recursive simulation
Op 01.mrt.2025 om 20:01 schreef olcott:
On 3/1/2025 10:05 AM, Richard Damon wrote:HHH emulating DD fails to reach the 'ret' instruction.
On 3/1/25 9:41 AM, olcott wrote:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally >>>>> proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally >>>>> proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally >>>>> proves non-termination whether aborted or not.
But it DOES terminate
DD emulated by HHH never terminates no matter how many
times you try to get away with the straw-man deception
of referring to anything at all besides
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
Because DD calls HHH(DD) in recursive emulation
thus non-termination is entirely the fault of DD.
On 3/1/2025 2:16 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 17:33 schreef olcott:
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:DD emulated by HHH according to the above x86 machine code of DD
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally >>>> proves failure of HHH to reach the end of a proven terminating program. >>>
cannot possibly reach its own "ret" instruction and terminate normally
In other words,
The DD input to HHH unequivocally specifies a
non terminating computation.
On 3/1/2025 4:39 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 22:11 schreef olcott:
On 3/1/2025 2:16 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 17:33 schreef olcott:
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:
On 3/1/2025 6:49 AM, Richard Damon wrote:proves failure of HHH to reach the end of a proven terminating
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck. >>>>>>>>
Cannot possibly reach its own "ret" instruction and terminate
normally
program.
DD emulated by HHH according to the above x86 machine code of DD
cannot possibly reach its own "ret" instruction and terminate normally >>>>
In other words,
The DD input to HHH unequivocally specifies a
non terminating computation.
What is the meaning of 'non terminating computation'?
The finite string input DD to HHH emulated by HHH according
to the behavior that it species (which includes pathological
self-reference) cannot possibly reach its "ret" instruction
and terminate normally.
When we say that the finite string input to HHH halts
because some other instance that is not an input halts
that is the same as saying that the Liar Paradox
is true because IT IS TRUE WHEN IT IS APPLIED TO ITSELF.
This sentence is not true: "This sentence is not true" IS TRUE.
On 3/1/2025 7:39 PM, dbush wrote:
On 3/1/2025 8:09 PM, olcott wrote:
On 3/1/2025 6:24 PM, dbush wrote:
On 3/1/2025 7:01 PM, olcott wrote:
On 3/1/2025 5:52 PM, dbush wrote:
On 3/1/2025 6:47 PM, olcott wrote:
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 add an additional complexity we must note that there are >>>>>>>> other
additional complexities that could be added instead.
Sure we could carefully examine every detail about the price
of tea in China.
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?
The answer is dead obviously "no" for everyone that is:
(a) Technically competent
and
(b) Not deliberately deceptive.
And by the same logic, no_numbers_greater_than_10 correctly
emulated by F cannot reach its own "ret" instruction, leading to
the conclusion that there are no natural numbers greater than 10,
and you are on record as admitting this is correct.
By this exact same reasoning the following function
void dbush_is-a-stupid_fool()
{
return;
}
Proves that dbush is a stupid fool.
I'll let you respond to yourself:
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders*
It was not an ad hominem attack because I know that you
are neither stupid nor a fool. Yet your reasoning was
both stupid and foolish.
Yet you failed to explain why it was wrong, thereby admitting it was
correct.
OK asshole if you only want to play head games I am done with you
On 3/1/2025 7:14 PM, Richard Damon wrote:(You seem to be the one with a (mis)attention problem.)
On 3/1/25 6:47 PM, olcott wrote:
On 3/1/2025 2:22 AM, Mikko wrote:
On 2025-03-01 00:47:58 +0000, olcott said:
When we are answering the question that seems impossible for anyoneWhen 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 add an additional complexity we must note that there are
other additional complexities that could be added instead.
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?
Not if you simulate it, which HHH does.The problem is that if HHH correctly emulates DD, then it can notThat is the same stupid shit as saying that no one can possibly tell
answer,
that an infinite loop will ever stop running unless they run it and wait until after the end of time.
On 3/1/2025 4:39 PM, Fred. Zwarts wrote:Yah.
Op 01.mrt.2025 om 22:11 schreef olcott:
On 3/1/2025 2:16 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 17:33 schreef olcott:
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
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.But then you just negated your first assumption, as a partial
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.
emulator that aborts its emulation, then DD no longer gets stuck. Exactly.
Cannot possibly reach its own "ret" instruction and terminateproves failure of HHH to reach the end of a proven terminating
normally
program.
Only when simulated, so that’s HHH’s fault.DD emulated by HHH according to the above x86 machine code of DD
cannot possibly reach its own "ret" instruction and terminate
normally
No, DD terminates.The DD input to HHH unequivocally specifies a non terminating
computation.
DD *is not running*. You are only talking about what HHH does.What is the meaning of 'non terminating computation'?
The finite string input DD to HHH emulated by HHH according to the
behavior that it species (which includes pathological self-reference)
cannot possibly reach its "ret" instruction and terminate normally.
When we say that the finite string input to HHH halts because some other instance that is not an input halts that is the same as saying that theDD *is* the input, not some other DD that calls HHH1 or HHH with
Liar Paradox is true because IT IS TRUE WHEN IT IS APPLIED TO ITSELF.
This sentence is not true: "This sentence is not true" IS TRUE.True.
On 3/1/2025 4:08 PM, Fred. Zwarts wrote:When HHH breaks the chain, there is no chain to break.
Op 01.mrt.2025 om 22:12 schreef olcott:
On 3/1/2025 2:22 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 20:01 schreef olcott:
On 3/1/2025 10:05 AM, Richard Damon wrote:
On 3/1/25 9:41 AM, olcott wrote:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
No, DD calls HHH only once.HHH emulating DD fails to reach the 'ret' instruction.But it DOES terminateCannot possibly reach its own "ret" instruction and terminateWhen 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.But then you just negated your first assumption, as a partial
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.
emulator that aborts its emulation, then DD no longer gets stuck. >>>>>>>>
normally proves non-termination whether aborted or not.
DD emulated by HHH never terminates no matter how many times you try >>>>> to get away with the straw-man deception of referring to anything at >>>>> all besides DD EMULATED BY HHH
Because DD calls HHH(DD) in recursive emulation thus non-termination
is entirely the fault of DD.
When DD is correctly emulated by HHH and DD calls HHH(DD)
then DD calls HHH in recursive emulation.
When HHH breaks this otherwise endless chain every level of DD
immediately stops with none of them ever reaching their "ret"
instruction.
On 3/1/2025 4:05 PM, Fred. Zwarts wrote:In other words(tm), you admit that paraphrases can be wrong.
Op 01.mrt.2025 om 22:11 schreef olcott:
On 3/1/2025 2:16 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 17:33 schreef olcott:
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
In other words, HHH did not terminate the simulation.The DD input to HHH unequivocally specifies a non terminatingproves failure of HHH to reach the end of a proven terminatingCannot possibly reach its own "ret" instruction and terminateWhen 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.But then you just negated your first assumption, as a partial
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.
emulator that aborts its emulation, then DD no longer gets stuck. >>>>>>>>
normally
program.
DD emulated by HHH according to the above x86 machine code of DD
cannot possibly reach its own "ret" instruction and terminate
normally
computation.
Your paraphrase seems intentionally dishonest at this point in our
dialogue.
On 3/1/2025 2:22 PM, Fred. Zwarts wrote:Cannot be. DD halts. HHH just can’t simulate it.
Op 01.mrt.2025 om 20:01 schreef olcott:
On 3/1/2025 10:05 AM, Richard Damon wrote:
On 3/1/25 9:41 AM, olcott wrote:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
HHH emulating DD fails to reach the 'ret' instruction.But it DOES terminateCannot possibly reach its own "ret" instruction and terminateWhen we hypothesize that the code at machine address 0000213c is >>>>>>> an x86 emulator then we know that DD remains stuck in recursiveBut then you just negated your first assumption, as a partial
emulation and cannot possibly reach its own "ret" instruction and >>>>>>> terminate normally.
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.
emulator that aborts its emulation, then DD no longer gets stuck.
normally proves non-termination whether aborted or not.
DD emulated by HHH never terminates no matter how many times you try
to get away with the straw-man deception of referring to anything at
all besides DD EMULATED BY HHH
Because DD calls HHH(DD) in recursive emulation thus non-termination is entirely the fault of DD.
On 3/1/2025 3:58 PM, Richard Damon wrote:You are asking for the impossible. HHH cannot simulate itself.
On 3/1/25 2:01 PM, olcott wrote:
On 3/1/2025 10:05 AM, Richard Damon wrote:
On 3/1/25 9:41 AM, olcott wrote:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
If it was actually incorrect then someone could show how the above codeWhich since HHH doesn't correctly emulate DD is just a fantasy.Cannot possibly reach its own "ret" instruction and terminateWhen we hypothesize that the code at machine address 0000213c is >>>>>>> an x86 emulator then we know that DD remains stuck in recursiveBut then you just negated your first assumption, as a partial
emulation and cannot possibly reach its own "ret" instruction and >>>>>>> terminate normally.
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.
emulator that aborts its emulation, then DD no longer gets stuck.
normally proves non-termination whether aborted or not.
But it DOES terminate
DD emulated by HHH never terminates no matter how many times you try
to get away with the straw-man deception of referring to anything at
all besides DD EMULATED BY HHH
is correctly emulated by HHH.
On 3/1/2025 4:39 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 22:11 schreef olcott:
On 3/1/2025 2:16 PM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 17:33 schreef olcott:
On 3/1/2025 9:39 AM, Fred. Zwarts wrote:
Op 01.mrt.2025 om 15:41 schreef olcott:
On 3/1/2025 6:49 AM, Richard Damon wrote:proves failure of HHH to reach the end of a proven terminating
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck. >>>>>>>>
Cannot possibly reach its own "ret" instruction and terminate
normally
program.
DD emulated by HHH according to the above x86 machine code of DD
cannot possibly reach its own "ret" instruction and terminate normally >>>>
In other words,
The DD input to HHH unequivocally specifies a
non terminating computation.
What is the meaning of 'non terminating computation'?
The finite string input DD to HHH emulated by HHH according
to the behavior that it species (which includes pathological
self-reference) cannot possibly reach its "ret" instruction
and terminate normally.
On 3/1/2025 3:58 PM, Richard Damon wrote:Invalid logic. If there a correct way does not exist, Oloctt is
On 3/1/25 2:01 PM, olcott wrote:
On 3/1/2025 10:05 AM, Richard Damon wrote:
On 3/1/25 9:41 AM, olcott wrote:
On 3/1/2025 6:49 AM, Richard Damon wrote:
On 2/28/25 7:47 PM, olcott wrote:
_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.
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.
But then you just negated your first assumption, as a partial
emulator that aborts its emulation, then DD no longer gets stuck.
Cannot possibly reach its own "ret" instruction and terminate normally >>>>> proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally >>>>> proves non-termination whether aborted or not.
Cannot possibly reach its own "ret" instruction and terminate normally >>>>> proves non-termination whether aborted or not.
But it DOES terminate
DD emulated by HHH never terminates no matter how many
times you try to get away with the straw-man deception
of referring to anything at all besides
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
DD EMULATED BY HHH
Which since HHH doesn't correctly emulate DD is just a fantasy.
If it was actually incorrect then someone could show
how the above code is correctly emulated by HHH.
On 3/1/2025 7:14 PM, Richard Damon wrote:
On 3/1/25 6:47 PM, olcott wrote:
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 add an additional complexity we must note that there are other >>>> additional complexities that could be added instead.
Sure we could carefully examine every detail about the price
of tea in China.
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?
The problem is that if HHH correctly emulates DD, then it can not answer,
That is the same stupid shit as saying that no one
can possibly tell that an infinite loop will ever
stop running unless they run it and wait until after
the end of time.
Since you are not stupid why do you say such stupid shit?
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 add an additional complexity we must note that there are other
additional complexities that could be added instead.
Sure we could carefully examine every detail about the price
of tea in China.
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?
The answer is dead obviously "no" for everyone that is:
(a) Technically competent
and
(b) Not deliberately deceptive.
On 3/1/2025 7:14 PM, Richard Damon wrote:
On 3/1/25 6:47 PM, olcott wrote:
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 add an additional complexity we must note that there are other >>>> additional complexities that could be added instead.
Sure we could carefully examine every detail about the price
of tea in China.
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?
The problem is that if HHH correctly emulates DD, then it can not answer,
That is the same stupid shit as saying that no one
can possibly tell that an infinite loop will ever
stop running unless they run it and wait until after
the end of time.
Since you are not stupid why do you say such stupid shit?
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 53:20:22 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,394 |
| Posted today: | 1 |