Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point?

On 6/8/2024 3:47 PM, Richard Damon wrote:

On 6/8/24 4:34 PM, olcott wrote:

On 6/8/2024 3:23 PM, Richard Damon wrote:

On 6/8/24 1:10 PM, olcott wrote:

On 6/8/2024 11:03 AM, Richard Damon wrote:

On 6/8/24 11:32 AM, olcott wrote:

On 6/8/2024 10:15 AM, Richard Damon wrote:

On 6/8/24 11:07 AM, olcott wrote:

On 6/8/2024 9:54 AM, Richard Damon wrote:

On 6/8/24 10:20 AM, olcott wrote:

On 6/8/2024 9:10 AM, Richard Damon wrote:

>
I HAVE pointed out what is missing, ANY set of truth-perserving operations from the accepted facts (which will of course need to name the fact they are working from) to your conclusion.

>
The accepted facts are here
(a) The x86 language
(b) The notion of an x86 emulator
>
{The proof that No DDD correctly emulated by any x86
  emulator H can possibly reach its own [00001df6] instruction}

>
So, how do you show this claim?
>
Do you have a tracing of the full INFINITE SET of possible Hs?
>

>
Is the set of possible execution traces of DDD correctly
emulated by x86 emulator HH on the basis of the above
accepted facts.
>
Maybe you are just clueless about these technical details
are are trying to hide this with pure bluster.
>
_DDD()
[00001de2] 55         push ebp
[00001de3] 8bec       mov ebp,esp
[00001de5] 8b4508     mov eax,[ebp+08]
[00001de8] 50         push eax         ; push DD
[00001de9] 8b4d08     mov ecx,[ebp+08]
[00001dec] 51         push ecx         ; push DD
[00001ded] e890f5ffff call 00001382    ; call HH
[00001df2] 83c408     add esp,+08
[00001df5] 5d         pop ebp
[00001df6] c3         ret
Size in bytes:(0021) [00001df6]
>
You keep disagreeing with the fact that DDD correctly
emulated by x86 emulator HH only has one single correct
execution trace of repeating the fist seven lines until
out-of-memory error.
>

>
But that is an INCORRECT trace per your definition,
>
The call HH instruction MUST be simulated into HH because that IS the behavior of the x86 instruction.

>
Did I ever say that it is not?
For the above DDD correctly emulated by x86 emulator HH
the first seven instructions of DD keep repeating because
DDD keeps calling HH(DDD,DDD) to emulate itself again and
again until HH/DDD hits out-of-memory exception.

>
So the x86 emulation of the code must go into HH(DDD,DDD)
>

>
It is pretty stupid to assume otherwise when HH is
stipulated to be an x86 emulator.

>
Right, so why did you say otherwise?
>

>
I never said otherwise you simply "read" meanings that I didn't say.
this thread: [Should I quit Richard at this point?]
stands alone and should not be interpreted within the
context of anything else that I ever said.

>
So, we are NOT to use your previous statements for earlier posts?
>
You keep on changing you mind, and not being clear. That shows your deceitful nature.
>

I must increasing narrow the focus of attention to ever
get any closure on as many as one single point.
>
The one point now is that DD correctly simulated by HH
proves that HH is correct to reject DD as non-halting.

 Which is incorrect, because you are using the wrong definition of correct simulation.
 

>
For three years every reviewer has essentially insisted that the
correct measure of the behavior of DD is DD incorrectly simulated
by HH. The behavior of the directly executed DD(DD) cannot possibly
be achieved by DD correctly simulated by HH as the x86 machine-code
of DD *conclusively proves BEYOND ALL POSSIBLE DOUBT*
>

Nope, and if that is what your though, you are just an idiot.
 

When one disagrees with the execution trace that x86 code specifies
one is essentially doing the same thing as disagreeing with arithmetic.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer