Re: DDD emulated by HHH --- (does not refer to prior posts)

On 9/9/24 1:57 PM, olcott wrote:

On 9/8/2024 9:41 AM, Mikko wrote:

On 2024-09-08 13:51:25 +0000, olcott said:
>

On 9/8/2024 4:19 AM, Mikko wrote:

On 2024-09-07 13:51:47 +0000, olcott said:
>

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:
>

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

>
_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]
>
Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

>
Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.
>

>
That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

>
There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

>
I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

>
Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.
>

>
Now there is a permanent link to the full file of the complete proof
https://www.liarparadox.org/HHH(DDD).pdf

>
There is no proof in that file.
>

 That the execution trace of DDD emulated by HHH is proven
by the x86 source code of DDD. That HHH correctly emulates
itself emulating DDD is proven by the fact that the second
execution trace provided by the emulated HHH matches the
x86 source code of DDD. That DDD cannot possibly reach
it "ret" instruction final halt state is proven by these
two execution traces and the source-code of DDD.

No, that is NOT the exectution trace of the correct emulation of the input, because the correct emulation of the input traces through the instructions of HHH as it emulates its input (the input is not executed again until HHH returns).
The second execution trace just proves that you are LYING about what is happening, because that NEVER HAPPENS as actually executed code.

 All this taken together proves that HHH had to abort its
emulation of DDD to prevent the infinite execution of DDD.
*Which proves that this criterion has been met*

Nope, just proves you are a liar.

 <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
 

Except that HHH never CORRECTLY determined that a CORRECT (and complete) emulation of *THIS* input would not halt, just that THIS HHH can't do it.