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.
Note, your TOPIC still indicates we are talking about Halting.
You should not be reusing names for very different things.
If HH is just a simulator, it should be called
In that case, why do we care about any of this, if D isn't supposed to be the D of the proofs, why do we care at all about it?
My guess is you are just losing your mental facilities and are forgetting what you are trying to do.
>
The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get to the sequence of instrucitions starting at 00001DE2, as the code will never jump there to just execute it.
>
>
Your are saying that incorrectly DDD correctly emulated by
x86 emulator HH cannot possibly reach it own machine address
of [00001df6].
>
I said nothing about that. You are just serving Herring with Red Sauce agian.
>
>>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get
>>> to the sequence of instructions starting at 00001DE2
WHO CARES.
Since you just admitted that DDD isn't at all related to the H^ of Linz or D or Sipser, and neither is HH the H of eaither, why should anyone care?
Wrong! DDD correctly simulated by HH will never reach its own
machine address of 00001df6 because DDD correctly simulated
by HH keeps starting over with another instance of itself at
00001DE2 after the prior instance calls HH(DDD,DDD) to simulate
itself again.
No, it will NOT "restart" as the code didn't reset.
You just don't seem to understand the meaning of your own defintion of correct simulation.
If HH is correctly simulating the x86 code it sees, then it simulates the code of DDD, then the code of HH simulating the code of DDD, then the code of HH now simulating the code of HH simulating the code of DDD
it NEVER gets back to simulating the code of DDD.
The CORRECT simulation of DDD can NEVER get back to the sequence of instructions at 00001DE2, as there is never a jump to that address, only the emulator starting an emuation of that address, and the correst simulation of a simulatore is NOT the code the simulated simulator is looking at, but the code of the simulator doing the simulation.
>
DDD correctly simulated by HH will never reach its own
machine address of 00001df6 because DDD correctly simulated
by HH keeps starting over with another instance of itself at
00001DE2 after the prior instance calls HH(DDD,DDD) to simulate
itself again.
Nope, it appear to get stuck in HH simulating itself, simulating itself, ...
It NEVER gets back to DDD.
>
By your code, the simulator will "Debug Step" those instructions.
>
>
The underlying details of one HH are irrelevant when I reference
an infinite set:\
>
But not for your definition of the simulation.
>
>
{The proof that No DDD correctly emulated by
any x86 emulator H
any x86 emulator H
any x86 emulator H
any x86 emulator H
any x86 emulator H
any x86 emulator H
can possibly reach its own [00001df6] instruction}
>
It seems that by your current analysis, it can't get past the instruction at 00001DED as there is nothing to simulate after that.
>
*A stupid thing to say*
>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>> [00001df2] 83c408 add esp,+08
>>>>>> [00001df5] 5d pop ebp
>>>>>> [00001df6] c3 ret
>>>>>> Size in bytes:(0021) [00001df6]
But the program counter is not at 0001382 due to the call instruction.
I guess you don't understand the details of what a call instruction does on the x86 processor.
Remember, your definition said to simulate the instructions in the strict order they were reached.
>
If we don't have the instruction at 00001382, the simulation has to stop, as we can't go on.
>
*A stupid thing to say*
>>>>>> _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]
It has been stipulated that there is ALWAYS an x86
emulator at the address 00001382.
So the simulator should simulate the simulator.
THAT would be the correct simulation of the code.
You just don't understand what you words mean.
Please show me your x86 reference were a specific call instruction behaves the way you claim.
Failure to do so will be an admisssion that you don't understand what you are talking about.
>
>
By a pure emulator, that would mean translating the machine code into the operations it will perform, and then manipulating the virtual register set being kept by the emulator.
>
>
libx86emu does that.
>
And if HH is a pure emulator, it need to do it to (or let libx86emu do it for it). and HH can't interfear with that process by not following each instruction with the instruction that follows it.
>
This thread is only about what you have already agreed to dozens
of times and you fail to notice that because rebuttal is your
game and honest dialogues are most always off-the-table for you.
*Ben already agreed that the criteria that*
*Professor Sipser agreed to have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
Right, if H is not defined to be a halt decider, but an H can not simulate decider, you can do it for this one case.
But that means admitting that H isn't a Halt decider.
You want to always ignore that so you can remain in rebuttal
mode at the expense of truth.
Nope, I stand for truth, YOU LIE.
So, does the libx86emu keep a seperate logging of the instructions that HH is emulating, as would be needed for HH to be able to examine that trace.
>
The previous trace you posted wasn't the simulation that HH was doing, but was a trace of the execution of HH iteself.
>
It seems that HH doesn't actual have a trace of what it did available (or at least you didn't show it).
>
LIAR LIAR PANTS ON FIRE
I HAVE SHOWN THIS TRACE AGAIN AND AGAIN FOR THREE YEARS
And it is still wrong for your cleaned up definiton of correct simulation..
Begin Local Halt Decider Simulation Execution Trace Stored at:113075
[00001c22][00113061][00113065] 55 push ebp
[00001c23][00113061][00113065] 8bec mov ebp,esp
[00001c25][0011305d][00103031] 51 push ecx
[00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
[00001c29][00113059][00001c22] 50 push eax ; push DD
[00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][00113055][00001c22] 51 push ecx ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
New slave_stack at:14da95
THIS JUST DOESN'T HAPPEN by your definition of correct simulation.
Either the simulator need to halt because it ran out of code to simulate, or it needs to simulate the code at 00001342.
The code NEVER gets to the begin of DDD in the actual top level thread of simulation.
Your "Trace" mixes up different simulations.
[00001c22][0015da89][0015da8d] 55 push ebp
[00001c23][0015da89][0015da8d] 8bec mov ebp,esp
[00001c25][0015da85][0014da59] 51 push ecx
[00001c26][0015da85][0014da59] 8b4508 mov eax,[ebp+08]
[00001c29][0015da81][00001c22] 50 push eax ; push DD
[00001c2a][0015da81][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][0015da7d][00001c22] 51 push ecx ; push DD
[00001c2e][0015da79][00001c33] e80ff7ffff call 00001342 ; call HH
Local Halt Decider: Recursive Simulation Detected Simulation Stopped
First published complete execution trace proving that D is correctly
simulated by H and correctly simulated by simulated H. The proof of
this that everyone has ignored for three solid years is that the derived
execution traces exactly match the behavior specified by the x86
machine code of D.
On 5/29/2021 2:26 PM, olcott wrote:
[Would the simulation of D be infinitely nested unless simulating partial halt decider H terminated its simulation of D?]
Message-ID: <YJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d@giganews.com>
But then, you always seemed to have gotten the "levels" of simulation incorrect.
>
No you just lie about this.
Really then why does your trace show two different levels of simulation, if the simulation is actually the correct simulation as you have defined.
This just shows you don't know the meaning of "correct"
>
>
If your "simulation" is ACTUALLY being done using the debug step hardware of the system (or simulating the actions of that hardware) then the instruction are executed, but not in sequence as they have all the steps of the debugger/tracing around them.
>
>
That is not how x86 emulators work.
>
But it is what "Debug Step" implies.
>
It <is> a Debug_Step though the emulated code.
You keep freaking forgetting what the Hell an emulator is.
Do you know what an ACTUAL "DEBUG STEP" is?
It is NOT "emulate one instruction"!
It is a hardware feature that allows the debugger to DIRECTLY EXECUTE exactly one instruction, and then have an interrupt triggered so the debugger gets back into control.
Note, this capability requires the process doing it to have been granted specific privileges, and for that debugger process to attach to the process being debugged and stepped.
Maybe you should read the hardware manuals for the processor you claim to be an expert on. And you need to go beyond the normal programmer sections, into the privileged OS instructions.
Or, are you not familiar with that part of the x86 hardware.
>
Yes.
So, you agree you are not familiar with the x86 debugger features?
>
So, your claim of what happens just shows you don't understand what the program you are using actually is doing.
>
>
No it shows that you don't know how x86 emulators work.
>
So, what did I not understand?
>
You keep freaking forgetting what the Hell an emulator is.
And emulators do not "debug Step" because they have no need to do that.
They can just do an emulate 1 instruction call, which is likely a basic function of the emulator function.
>
That might explain why the trace you posted the other day wasn't actually the trace you claimed it was.
>
>
We are only focusing on this one thread and zero deflection
will be tolerated.
>
Ok, so why doesn't your HH here trace into HH
>
As I have said 5,000 times when people cannot possibly
understand 1/2 of one page of code mixing in another 250
pages cannot possibly help.
But the trace you posted that was 250 pages wasn't the trace produces by HH, but a trace by the x86 of HH running and doing the simulation. That isn't what was asked for.
I guess a trace of just what HH emulated to be less that 50 pages, if that long. That trace would start with the first instruction of DD, and then the code of HH setting up and doing those 8 instructions at which point HH will detect the recursion and abort it simulation.
And why does it start to show a trace of instructions that are never actually directly simulated by the HH that we are talking about>
>
I have already proved THREE FREAKING YEARS AGO
that D is correctly simulated by H and D is correctly
simulated by simulated H.
Nope. not by the right definition of simulation, and since you revised your defintion, not ever by YOUR defintion. Remember, you have now defined it as the exact x86 instructions exactly executed in the exact order the processor reaches them.
After the processor executes the CALL HH instruction, that continues into the subroutine HH, and by your code NEVER LEAVES IT.
At no point does this thread of execution reach DD again.
Where you try to show that, is a DIFFERENT level of simulation. You would need a different definition of "Correct Simulation" to make that part of it.
That everyone has ignored this proof is probably
because they were trying to hide their own cluelessness.
Nope, just ignoring your lies.
>
>
This is the only post that I will reply to you on.
I need you to stay focused on this one single point
until you understand it.
>
Is that a promise? I think you will break it.
>
>
When you proved to break out of your "stuck in rebuttal mode"
nonsense and talked about closure I backed off this requirement
for a while.
>
*Even Ben admits that H does meet the Sipser criteria*
>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
>
>
Nope, he is just pointing out your circular logic.
>
LIAR LIAR PANTS ON FIRE
And you seem to be heading for the lake of FIRE.
Yes, P(P) won't halt if the code of H won't abort it.
>
thus meeting the Sipser approved criteria.
Nope. SInce H DOES abort its simulation, conditions based on it not don't apply.
Sipser ONLY looks that THIS INPUT which doesn't change when your hypotosize about diffferent behaviors for H
But if the code of H does abort it, it will halt.
>
D is accountable for the behavior of its actual input and
not freaking accountable for any damn thing else in the
whole freaking universe.
Nope. D is accountable for confounding H.
H is accountable for the behavior of the machine its input represents.
That there is a consensus of opinion against this is
just like the consensus of opinion that the Earth was flat
prior to Pythagoras.
Nope, It is the definiton of the GODS of the theory.
Halt deciders compute the mapping FROM THEIR INPUTS
BASED ON THE ACTUAL BEHAVIOR THAT THIS INPUT SPECIFIES.
This input specifies the behavior of DD correctly
simulated by HH.
And that actual behavior is DEFINED as the behavior of the machibne represent by the input when directly executed.
That everyone wants to avoid looking at my conclusive
proof that DD correctly simulated by HH has provably
different behavior than the direct executed DD(DD) is
dishonest.
No, it is because you keep on admitting that you are using the wrong definition, and then claiming you are allowed to do it.
You aren't, and the GODS of the theory have cast you out into the lake of FIRE.
The Halting Question is about the behavior of the directly executed program represented by the input. Since you admit to usign a different criteria, you are admitting that it isn;t halting by Peter Olcott's Other Problem that you are actually talking about, and no one really cares about your POOP. or your transparent LIES when you try to claim you are talking about halting.
Thus, if the question actually WAS "Will the template P(P) Halt if the decider it is pair with doesn't abort its simulation", then he agreed you could answer No.
>
But that isn't the Halting Question, so it isn't the correct answer to the question that H is supposed to answer.
Why does Olcott care about simulation, anyway?
Re: Why does Olcott care about simulation, anyway?