People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper* https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
On 6/29/2024 11:45 AM, Richard Damon wrote:
On 6/29/24 12:09 PM, olcott wrote:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
Nope, we are not disagreeing with the semantics of the x86 language, we
are disagreeing with your misunderstanding of how it works.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
No the x86 language "knows" NOTHING about H0 being a x86 emulator. It
is just a function that maybe happens to be a partial x86 emulator, but
that is NOT a fundamental result of it being H0.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
It is construed as non-halting BECAUSE it has been shown that your H0
*WILL* terminate its PARTIAL emulation of the code it is emulating and
returning.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
Right, so H0 is REQUIRED to return, and thus if the termination
analyser knows that H0 is a termination analyzer it knows that the call
to H0 MUST return, and thus DDD must be a terminating program.
An H0 that doesn't know this, and can't figure out that H0 will return,
but just keeps emulating H0 emulating its input will just fail to meet
its own requirement to return.
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Right, and the only definition Professor Sipser uses for "Correct
Simulation" is a simulation that EXACTLY REPRODUCES the behavior of the
directly executed program represented by the input. Your H doesn't do
that, nor correctly predicts the behavior of such a simulation of the
input (since that behavior is to halt) so it can never proper avail
itself of the second paragraph, so does so erroneously getting the
wrong answer.
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
Except that the "N Steps of DDD correctly emulated" is NOT the
definition of the "behavior" of the input DDD.
"inputs" Do not have "behavoir", that is a property of a program, so
the input only "represents" that program, in this case the program DDD.
*According to the professor Sipser approved criteria YES IT IS*
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
On 6/29/2024 6:46 PM, Richard Damon wrote:
On 6/29/24 6:54 PM, olcott wrote:
On 6/29/2024 4:19 PM, Richard Damon wrote:
On 6/29/24 4:33 PM, olcott wrote:
On 6/29/2024 3:25 PM, Richard Damon wrote:
On 6/29/24 4:17 PM, olcott wrote:
On 6/29/2024 3:10 PM, Richard Damon wrote:
On 6/29/24 3:25 PM, olcott wrote:
On 6/29/2024 2:08 PM, Richard Damon wrote:
On 6/29/24 2:47 PM, olcott wrote:
On 6/29/2024 1:38 PM, Richard Damon wrote:
On 6/29/24 2:06 PM, olcott wrote:
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
But that only applies if H determines a CORRECT SIMULATION per HIS >>>>>>>> definition does not halt
.
That means the DIRECT EXECUTION of the program represented by the input
does not halt, since that is the DEFINITION of the results of a correct
simuation.
That also requires that the simulation does not stop until it reaches a
final state. You H neither does that nor correctly determines that >>>>>>>> (since it does halt) thus you can never use the second paragraph to be >>>>>>>> allowed to abort, even though you do anyway, which is why you get the >>>>>>>> wrong answer.
*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
Which does not determine the ACTUAL behavor
_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]
That you already know that it does prove that DDD correctly >>>>>>>>>>> emulated by HHH would never stop running unless aborted
or out-of-memory error
*proves that you are trying to get away with a bald-faced lie* >>>>>>>>>>> I really hope that you repent before it is too late.
Nope, just shows your stupidity, as the above code has NO defined >>>>>>>>>> behavior as it accesses code that is not defined by it.
*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
the recursive emulation call from DDD to HHH(DDD).
But by the semantics of the x86 langugage, the call to HHH does NOT do >>>>>>>> a "recursive simulation" since that is not a term in that language. >>>>>>>>
The Call to HHH just cause the
(b) The semantics of the x86 language.
(c) That HHH is an x86 emulator that correctly emulates
N steps of DDD.
Which isn't an ACTUALY correct emulation, but only a PARTIAL correct >>>>>>>> emulation (since correct emulation implies EVERY instruction but a >>>>>>>> terminal one is followed by the next instruction).
The key fact is that PARTIAL emulation doesn't reveal the future of the
behavior past the point of the emulation.
In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:
H correctly simulates its input D until H correctly determines
that its simulated D would never stop running unless aborted
Nope, he just laid a trap that you fell into.
He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.
Right, and he could have seen the errors in your apparent
misunderstanding of the words and accepted them, knowing that they were >>>> actually meaningless.
The ONLY simulation that Professor Sipser accepts as correct, is one >>>>>> that shows EXACTLY the behavior of the machine being simulated.
So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?
The question said NOTHING of the x86 language, so it doesn't matter.
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
But the question to Professor Sipser was, as you quoted:
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Which said NOTHING about the x86 language,
So, who is the liar now?
_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]
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
Which wasn't what we were talking about with Professor Sipser, who
never saw any of that.
I guess you just have a major brain malfunction and can't keep your
lies straight.
This just proves your unreliability when it comes to statements
Partial halt deciders constructed for the x86 language
are isomorphic to this termination analyzer build for
the C programming language.
*AProVE: Non-Termination Witnesses for C Programs*
To prove (non-)termination of a C program, AProVE uses the
Clang compiler [7] to translate it to the intermediate
representation of the LLVM framework [15]. Then AProVE
symbolically executes the LLVM program and uses abstraction
to obtain a finite symbolic execution graph (SEG) containing
all possible program runs. https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf
Even a Turing machine based partial halt decider is
locked in to the Turing Machine description language.
Is this really over your head?
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the
HHH that is calld by DDD won't eventually return.
So finally you quit lying.
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the
HHH that is calld by DDD won't eventually return.
So finally you quit lying.
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the
HHH that is calld by DDD won't eventually return.
Since you assert that HHH(DDD) called by main returns, then by your
requreement that HHH be a "pure function" ALL copies of it will do the
same thing.
Yes, the EMULATION of HHH by HHH, but that can not be the "behavior of
the input" as that "behavior" depends on more than just the input.
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the
HHH that is calld by DDD won't eventually return.
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
On 6/30/2024 4:57 PM, Richard Damon wrote:
On 6/30/24 5:48 PM, olcott wrote:
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
People are trying to get away with disagreeing with the semantics >>>>>>> of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the
HHH that is calld by DDD won't eventually return.
Since you assert that HHH(DDD) called by main returns, then by your
requreement that HHH be a "pure function" ALL copies of it will do
the same thing.
Yes, the EMULATION of HHH by HHH, but that can not be the "behavior
of the input" as that "behavior" depends on more than just the input.
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
And then it doesn't correct emulate the input, and thus is a LIAR.
You already know that you are the liar here and are
lying about not knowing this.
_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]
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
On 6/30/2024 5:04 PM, Richard Damon wrote:
On 6/30/24 6:00 PM, olcott wrote:
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
People are trying to get away with disagreeing with the semantics >>>>>>> of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the
HHH that is calld by DDD won't eventually return.
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
And HHH can not report that fact, because, to correct emulate, as
presuemd, it can not stop it emulation.
If it does, it changes the behavior of DDD (remember, the code of HHH
is PART of the code for DDD) and DDD will Halt.
You are just showing you are a stupid LIAR.
*YOU ALREADY ADMITTED THAT I AM CORRECT*
On 6/30/2024 2:31 PM, Richard Damon wrote:
What in the sematics of the x86 language, which
INCLUDES that ever instruction WILL be followed
by the next instruction, says that the HHH
that is calld by DDD won't eventually return.
*THIS PROVES THAT DDD CORRECTLY EMULATED BY HHH DOES NOT HALT*
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
_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]
On 6/30/2024 6:14 PM, Richard Damon wrote:
On 6/30/24 6:41 PM, olcott wrote:They need not be the FULL behavior of the input.
On 6/30/2024 4:57 PM, Richard Damon wrote:
On 6/30/24 5:48 PM, olcott wrote:
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop, >>>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations >>>>>>>>> so that itself can terminate normally.
When this is construed as non-halting criteria then simulating >>>>>>>>> termination analyzer H0 is correct to reject these inputs as >>>>>>>>> non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior >>>>>>>>> that their finite string input specifies thus H0 must report >>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive >>>>>>>>> simulation.
<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
H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
People are trying to get away with disagreeing with the semantics >>>>>>>>> of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>>>>> return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever >>>>>> instruction WILL be followed by the next instruction, says that
the HHH that is calld by DDD won't eventually return.
Since you assert that HHH(DDD) called by main returns, then by
your requreement that HHH be a "pure function" ALL copies of it
will do the same thing.
Yes, the EMULATION of HHH by HHH, but that can not be the
"behavior of the input" as that "behavior" depends on more than
just the input.
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
And then it doesn't correct emulate the input, and thus is a LIAR.
You already know that you are the liar here and are
lying about not knowing this.
_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]
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
The problem is that the N steps emulated by HHH are not, and CAN NOT
be the "behavior of the input",
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly determines that its simulated D would never
stop running unless aborted
On 6/30/2024 6:53 PM, Richard Damon wrote:
On 6/30/24 7:18 PM, olcott wrote:
On 6/30/2024 6:14 PM, Richard Damon wrote:
On 6/30/24 6:41 PM, olcott wrote:They need not be the FULL behavior of the input.
On 6/30/2024 4:57 PM, Richard Damon wrote:
On 6/30/24 5:48 PM, olcott wrote:
On 6/30/2024 2:31 PM, Richard Damon wrote:
On 6/30/24 1:18 PM, olcott wrote:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with >>>>>>>>>>> the semantics of the x86 language. That is isomorphic to >>>>>>>>>>> trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows >>>>>>>>>>> that when H0 emulates the machine language of Infinite_Loop, >>>>>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations >>>>>>>>>>> so that itself can terminate normally.
When this is construed as non-halting criteria then simulating >>>>>>>>>>> termination analyzer H0 is correct to reject these inputs as >>>>>>>>>>> non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior >>>>>>>>>>> that their finite string input specifies thus H0 must report >>>>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive >>>>>>>>>>> simulation.
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
People are trying to get away with disagreeing with the
semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>>>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>>>>>>> return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged >>>>>>>>>> disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that
ever instruction WILL be followed by the next instruction, says >>>>>>>> that the HHH that is calld by DDD won't eventually return.
Since you assert that HHH(DDD) called by main returns, then by >>>>>>>> your requreement that HHH be a "pure function" ALL copies of it >>>>>>>> will do the same thing.
Yes, the EMULATION of HHH by HHH, but that can not be the
"behavior of the input" as that "behavior" depends on more than >>>>>>>> just the input.
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
And then it doesn't correct emulate the input, and thus is a LIAR. >>>>>>
You already know that you are the liar here and are
lying about not knowing this.
_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]
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
The problem is that the N steps emulated by HHH are not, and CAN NOT
be the "behavior of the input",
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
And that can NOT be the "Behavior of the Input" as it depends on more
that just the input.
DDD correctly emulated by HHH calls
an emulated HHH that emulates its own DDD
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
On 6/30/2024 7:13 PM, Richard Damon wrote:
On 6/30/24 8:00 PM, olcott wrote:
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
But it does, just after H gives up its simulation.
You have even show that with a simulation.
Liar Liar Pants on Fire !!!
Liar Liar Pants on Fire !!!
Liar Liar Pants on Fire !!!
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
H_Hat((u32)H_Hat);
}
_H_Hat()
[00000b98](01) 55 push ebp
[00000b99](02) 8bec mov ebp,esp
[00000b9c](03) 8b4508 mov eax,[ebp+08]
[00000b9f](01) 50 push eax
[00000ba0](03) 8b4d08 mov ecx,[ebp+08]
[00000ba3](01) 51 push ecx
[00000ba4](05) e88ffdffff call 00000938
[00000ba9](03) 83c408 add esp,+08
[00000bac](03) 8945fc mov [ebp-04],eax
[00000baf](04) 837dfc00 cmp dword [ebp-04],+00
[00000bb3](02) 7402 jz 00000bb7
[00000bb5](02) ebfe jmp 00000bb5
[00000bb7](02) 8be5 mov esp,ebp
[00000bb9](01) 5d pop ebp
[00000bba](01) c3 ret
Size in bytes:(0035) [00000bba]
_main()
[00000bc8](01) 55 push ebp
[00000bc9](02) 8bec mov ebp,esp
[00000bcb](05) 68980b0000 push 00000b98
[00000bd0](05) e8c3ffffff call 00000b98
[00000bd5](03) 83c404 add esp,+04
[00000bd8](02) 33c0 xor eax,eax
[00000bda](01) 5d pop ebp
[00000bdb](01) c3 ret
Size in bytes:(0020) [00000bdb]
===============================
...[00000bc8][001015d4][00000000](01) 55 push ebp ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98 ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98 ...[00000b98][001015c8][001015d4](01) 55 push ebp ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp ...[00000b9b][001015c4][00000000](01) 51 push ecx ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][001015c0][00000b98](01) 50 push eax ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][001015bc][00000b98](01) 51 push ecx ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
Begin Local Halt Decider Simulation at Machine Address:b98 ...[00000b98][00211674][00211678](01) 55 push ebp ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp ...[00000b9b][00211670][00201644](01) 51 push ecx ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0021166c][00000b98](01) 50 push eax ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][00211668][00000b98](01) 51 push ecx ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938 ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp ...[00000b9b][0025c098][0024c06c](01) 51 push ecx ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0025c094][00000b98](01) 50 push eax ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][0025c090][00000b98](01) 51 push ecx ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08 ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00 ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7 ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp ...[00000bba][001015d0][00000b98](01) c3 ret ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04 ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax ...[00000bda][001015d8][00100000](01) 5d pop ebp ...[00000bdb][001015dc][00000098](01) c3 ret
Number_of_User_Instructions(39)
Number of Instructions Executed(26567)
DDD correctly emulated by HHH calls an emulated HHH(DDD)
that emulates its own DDD that calls an emulated HHH(DDD)
that is either aborted at some point never returning or
hits out-of-memory error never returning
On 6/30/2024 7:44 PM, Richard Damon wrote:
On 6/30/24 8:27 PM, olcott wrote:
On 6/30/2024 7:13 PM, Richard Damon wrote:
On 6/30/24 8:00 PM, olcott wrote:
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
But it does, just after H gives up its simulation.
You have even show that with a simulation.
Liar Liar Pants on Fire !!!
Liar Liar Pants on Fire !!!
Liar Liar Pants on Fire !!!
Are you forgetting this message:
On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
void H_Hat(u32 P)[00000b9b](01) 51 push ecx
{
; u32 Input_Halts = Halts(P, P);
; if (Input_Halts)
; HERE: goto HERE;
}
;
;
int main()
{
; H_Hat((u32)H_Hat);
}
;
;
_H_Hat()
[00000b98](01) 55 push ebp >> > [00000b99](02) 8bec mov ebp,esp >> >
[00000b9c](03) 8b4508 mov eax,[ebp+08]
[00000b9f](01) 50 push eax >> > [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
[00000ba3](01) 51 push ecx >> > [00000ba4](05) e88ffdffff call 00000938
[00000ba9](03) 83c408 add esp,+08
[00000bac](03) 8945fc mov [ebp-04],eax
[00000baf](04) 837dfc00 cmp dword [ebp-04],+00
[00000bb3](02) 7402 jz 00000bb7 >> > [00000bb5](02) ebfe jmp 00000bb5 >> > [00000bb7](02) 8be5 mov esp,ebp >> > [00000bb9](01) 5d pop ebp
[00000bba](01) c3 ret
Size in bytes:(0035) [00000bba]
;
_main()
[00000bc8](01) 55 push ebp >> > [00000bc9](02) 8bec mov ebp,esp >> > [00000bcb](05) 68980b0000 push 00000b98
[00000bd0](05) e8c3ffffff call 00000b98
[00000bd5](03) 83c404 add esp,+04
[00000bd8](02) 33c0 xor eax,eax >> > [00000bda](01) 5d pop ebp
[00000bdb](01) c3 ret
Size in bytes:(0020) [00000bdb]
;
===============================
...[00000bc8][001015d4][00000000](01) 55 push ebp
...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
...[00000b98][001015c8][001015d4](01) 55 push ebp
...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
...[00000b9b][001015c4][00000000](01) 51 push ecx
...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
...[00000b9f][001015c0][00000b98](01) 50 push eax
...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] >> > ...[00000ba3][001015bc][00000b98](01) 51 push ecx
...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
Begin Local Halt Decider Simulation at Machine Address:b98
...[00000b98][00211674][00211678](01) 55 push ebp
...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
...[00000b9b][00211670][00201644](01) 51 push ecx
...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] >> > ...[00000b9f][0021166c][00000b98](01) 50 push eax
...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] >> > ...[00000ba3][00211668][00000b98](01) 51 push ecx
...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
...[00000b9b][0025c098][0024c06c](01) 51 push ecx
...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] >> > ...[00000b9f][0025c094][00000b98](01) 50 push eax
...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] >> > ...[00000ba3][0025c090][00000b98](01) 51 push ecx
...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and
is processed below:
...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08[ebp-04],+00
...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax >> > ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword
...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
...[00000bba][001015d0][00000b98](01) c3 ret
...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
...[00000bda][001015d8][00100000](01) 5d pop ebp
...[00000bdb][001015dc][00000098](01) c3 ret
SEE IT HALTED!
Number_of_User_Instructions(39)
Number of Instructions Executed(26567)
DDD correctly emulated by HHH calls an emulated HHH(DDD)
that emulates its own DDD that calls an emulated HHH(DDD)
that is either aborted at some point never returning or
hits out-of-memory error never returning
But HHH doesn't "Correctly Emulation" DDD by the definition that
provides the full behavior.
Since *THE* HHH DOES abort its emulation of *THIS* DDD, then THIS DDD
will return, just after this HHH has given up its emulation.
You LIE by confusing THIS HHH with another machine you try to also
call HHH, looking at a DIFFERENT input you deceptively try to also
call DDD that is different because it has been paired with that other
HHH.
None of that other behavior matters for THIS DDD.
You are just proving you don't understand the meaning of the words you
are using, but you MAKE UP fake defintions out of your IGNORANCE and
lie that they are the right definitions.
Sorry, it looks like you are fated for a Hot time in the future.
Your despicable lying strawman deception may work on fools
I am no fool.
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
_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]
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard
Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED.
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard
Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED. >>>>
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
And, since the HHH that DDD calls will abort is emulation, it WILL
return to DDD and it will return also.
How can stopping the emulation the first four
instructions of DDD possibly do anything besides
cause them to stop?
On 7/1/2024 3:32 AM, Fred. Zwarts wrote:
Op 30.jun.2024 om 19:18 schreef olcott:
On 6/30/2024 3:42 AM, Mikko wrote:
On 2024-06-29 16:09:19 +0000, olcott said:
People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.
<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
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
_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]
*A 100% complete and total rewrite of the prior paper*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
Nothing above is or points to any evdence about the alleged
disagreement.
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
A HHH aborting after N cycles of recursive simulation, needs to be
simulated by a simulator that allows at least N+1 cycles of recursion.
Otherwise the simulation is incomplete. This shows that such a HHH is
unable to correctly simulate itself.
HHH does emulated itself emulating DDD.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
Once aborted the DDD emulated by HHH immediately stops.
At no point in this emulation does the call from DDD
correctly emulated by HHH to HHH(DDD) ever return.
You can understand this or fail to understand this
disagreement is flat out incorrect.
On 7/1/2024 1:05 AM, Mikko wrote:The x86 semantics say that an aborted simulation returns.
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly simulated by
HHH calls HHH(DDD) that this call returns even though the semantics of
the x86 language disagrees.
You are inconsistent about whether HHH returns or not.It is your HHH so you should know whether it returns. Others may haveI have never lied about this.
wrong impression about it if they have trusted your lies.
DDD is emulated by HHH which calls an emulated HHH(DDD) toDDD running by itself does not stop. HHH stops simulating it.
repeat the process until aborted. Once aborted the DDD emulated by HHH immediately stops.
At no point in this emulation does the call from DDD emulatedWhere does the outer call to HHH get stuck after aborting?
by HHH to HHH(DDD) ever return.
On 7/1/2024 10:12 AM, Fred. Zwarts wrote:
Op 01.jul.2024 om 16:50 schreef olcott:
On 7/1/2024 9:37 AM, Fred. Zwarts wrote:
Op 01.jul.2024 om 14:46 schreef olcott:
On 7/1/2024 3:32 AM, Fred. Zwarts wrote:
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
Once aborted the DDD emulated by HHH immediately stops.
At no point in this emulation does the call from DDD
correctly emulated by HHH to HHH(DDD) ever return.
You can understand this or fail to understand this
disagreement is flat out incorrect.
I understand it, but that does not contradict that the abort is one
cycle too soon, which makes it incorrect.
On 7/1/2024 9:27 AM, Fred. Zwarts wrote:
Not aborting will loop infinitely.
That you disagree with your own self proves that you are wrong.
I did not disagree with myself. It is only you inability to understand
simple facts that :
It is not: Either aborting or not-aborting is incorrect,
but: Both aborting and not-aborting are incorrect.
Therefore, proving that not-aborting is incorrect does not prove that
aborting is correct.
You never found an error in this reasoning, but only repeat that
not-aborting is incorrect.
Somehow you seem to think that from "not-aborting is incorrect" it
follows that "aborting is correct".
Try to think a little bit. Both are incorrect.
If it is ever the case that
Not aborting will loop infinitely.THIS PROVES THAT ABORTING IS NECESSARILY CORRECT
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
IT IS 100% COMPLETELY CORRECT TO ABORT
It must abort to terminate the loop if the simulated HHH would not
terminate, but this simulated HHH does return after N+1 cycles and
therefore DDD will return, so here no abort is needed.
Abort is only needed if simulating an infinite recursion, not a
N-cycle recursion.
You are simply not bright enough to sufficiently understand this
criteria.
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
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(Infinite_Loop);
HHH(Infinite_Recursion);
HHH(DDD);
}
HHH is correct to abort all three.
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>>>>> Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO
DEFINED.
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
And, since the HHH that DDD calls will abort is emulation, it WILL
return to DDD and it will return also.
How can stopping the emulation the first four
instructions of DDD possibly do anything besides stop?
The emulation stops, and the emulating behavor of HHH stops, but not
the behavior of the input.
When DDD is no longer being emulated all of its behavior
stops. DDD is the input.
On 7/1/2024 7:38 PM, Richard Damon wrote:
On 7/1/24 8:49 AM, olcott wrote:
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
Richard Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>>>> DEFINED.
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
And, since the HHH that DDD calls will abort is emulation, it WILL >>>>>> return to DDD and it will return also.
How can stopping the emulation the first four
instructions of DDD possibly do anything besides stop?
The emulation stops, and the emulating behavor of HHH stops, but not
the behavior of the input.
When DDD is no longer being emulated all of its behavior
stops. DDD is the input.
Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT,
which isn't dependent on the emulator looking at it,
That is a stupid lie. In input is a static string when not
emulated and only becomes a dynamic process when emulated.
*Anyone with anything like a BSCS would know that*
On 7/1/2024 7:38 PM, Richard Damon wrote:
On 7/1/24 8:49 AM, olcott wrote:
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
Richard Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>>>> DEFINED.
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
And, since the HHH that DDD calls will abort is emulation, it WILL >>>>>> return to DDD and it will return also.
How can stopping the emulation the first four
instructions of DDD possibly do anything besides stop?
The emulation stops, and the emulating behavor of HHH stops, but not
the behavior of the input.
When DDD is no longer being emulated all of its behavior
stops. DDD is the input.
Nope. YOU don't understand the meaning of the terms, perhaps because
you don't understand what REALITY is.
The "Behavior of the Input" comes from the input alone, and doesn't
depend on the emulator doing anything.
Static strings do not become dynamic processes unless
and until they are simulated.
The emulation only REVEALS the behavior to the decider, not create it.
On 7/1/2024 9:00 PM, Richard Damon wrote:
On 7/1/24 9:42 PM, olcott wrote:
On 7/1/2024 7:38 PM, Richard Damon wrote:
On 7/1/24 8:49 AM, olcott wrote:
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, >>>>>>>>>> Richard Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>>>>>> DEFINED.
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
And, since the HHH that DDD calls will abort is emulation, it
WILL return to DDD and it will return also.
How can stopping the emulation the first four
instructions of DDD possibly do anything besides stop?
The emulation stops, and the emulating behavor of HHH stops, but
not the behavior of the input.
When DDD is no longer being emulated all of its behavior
stops. DDD is the input.
Nope. YOU don't understand the meaning of the terms, perhaps because
you don't understand what REALITY is.
The "Behavior of the Input" comes from the input alone, and doesn't
depend on the emulator doing anything.
Static strings do not become dynamic processes unless
and until they are simulated.
And THAT behavior is of the simulator.
Static Strings for Behavior Questions need to represent something that
HAS Behavior, which is a program, and the behavior in question will be
when that program is run.
Therefore when a interpreter interprets source-code
then this source-code remains a static text string
that cannot possibly be debugged dynamically because
it is just sitting there doing nothing.
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard Damon wrote:
I had to dumb this down because even the smartest
people here were overwhelmed:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.
But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED. >>>>>>
I don't understand why you so stupidly lie about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
And, since the HHH that DDD calls will abort is emulation, it WILL
return to DDD and it will return also.
How can stopping the emulation the first four
instructions of DDD possibly do anything besides stop?
The emulation stops, and the emulating behavor of HHH stops, but not
the behavior of the input.
When DDD is no longer being emulated all of its behavior
stops. DDD is the input.
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
It is your HHH so you should know whether it returns. Others may
have wrong impression about it if they have trusted your lies.
I have never lied about this.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
Once aborted the DDD emulated by HHH immediately stops.
At no point in this emulation does the call from DDD
correctly emulated by HHH to HHH(DDD) ever return.
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
It is your HHH so you should know whether it returns. Others may
have wrong impression about it if they have trusted your lies.
I have never lied about this.
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
It is your HHH so you should know whether it returns. Others may
have wrong impression about it if they have trusted your lies.
I have never lied about this.
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
It is your HHH so you should know whether it returns. Others may
have wrong impression about it if they have trusted your lies.
I have never lied about this.
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
It is your HHH so you should know whether it returns. Others may
have wrong impression about it if they have trusted your lies.
I have never lied about this.
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
Please, point to the paragraph in the specification of the X86
language that says that a two cycle recursion should be aborted after
one cycle.
Claiming that the abort is related to the x86 language is apparently
wilfully incorrect.
I am not going to show you the trace of the Peano axioms
that prove the 2 + 3 = 5, if you disagree you are a liar
or an ignoramus.
On 7/1/2024 7:38 PM, Richard Damon wrote:
On 7/1/24 8:49 AM, olcott wrote:
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
Richard Damon wrote:
And, since the HHH that DDD calls will abort is emulation, it WILL >>>>>> return to DDD and it will return also.
The emulation stops, and the emulating behavor of HHH stops, but not
the behavior of the input.
The "Behavior of the Input" comes from the input alone, and doesn'tStatic strings do not become dynamic processes unless and until they are simulated.
depend on the emulator doing anything.
The emulation only REVEALS the behavior to the decider, not create it.
On 7/1/2024 7:38 PM, Richard Damon wrote:Defined that way, there is no notion of the input halting or not AT ALL.
On 7/1/24 8:49 AM, olcott wrote:
On 7/1/2024 6:08 AM, Richard Damon wrote:
On 6/30/24 10:27 PM, olcott wrote:
On 6/30/2024 9:16 PM, Richard Damon wrote:
On 6/30/24 9:38 PM, olcott wrote:
On 6/30/2024 8:24 PM, Richard Damon wrote:
On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
Richard Damon wrote:
Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT,The emulation stops, and the emulating behavor of HHH stops, but notAnd, since the HHH that DDD calls will abort is emulation, it WILL >>>>>> return to DDD and it will return also.How can stopping the emulation the first four instructions of DDD
possibly do anything besides stop?
the behavior of the input.
When DDD is no longer being emulated all of its behavior stops. DDD is
the input.
which isn't dependent on the emulator looking at it,
That is a stupid lie. In input is a static string when not emulated and
only becomes a dynamic process when emulated.
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
If it returns, it doesn’t need to be aborted.It is your HHH so you should know whether it returns. Others may >>>>>>>> have wrong impression about it if they have trusted your lies.
It is very easy to show.Please, point to the paragraph in the specification of the X86I am not going to show you the trace of the Peano axioms that prove
language that says that a two cycle recursion should be aborted after
one cycle.
the 2 + 3 = 5, if you disagree you are a liar or an ignoramus.
DDD correctly emulated by HHH calls an emulated HHH(DDD) that emulatesBut HHH aborts, so the cycle does end.
DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this >>>>>>>>> verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>>>>> return.
It is your HHH so you should know whether it returns. Others may >>>>>>>> have wrong impression about it if they have trusted your lies.
I have never lied about this.
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
Please, point to the paragraph in the specification of the X86
language that says that a two cycle recursion should be aborted
after one cycle.
Claiming that the abort is related to the x86 language is apparently
wilfully incorrect.
I am not going to show you the trace of the Peano axioms
that prove the 2 + 3 = 5, if you disagree you are a liar
or an ignoramus.
This change of subject does not hide that your claim that the x86
language proves your claim is incorrect as a verified fact.
So you opted for liar then:
_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]
DDD correctly emulated by HHH calls an emulated HHH(DDD)
that emulates DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
On 7/3/2024 10:59 AM, Fred. Zwarts wrote:Anyone knowing the x86 language knows that a program cannot be
Op 03.jul.2024 om 15:21 schreef olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:I have never lied about this.
Richard just said that he affirms that when DDD correctly >>>>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even >>>>>>>>>>> though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this >>>>>>>>>>> verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>>>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>>>>>>> return.
It is your HHH so you should know whether it returns. Others may >>>>>>>>>> have wrong impression about it if they have trusted your lies. >>>>>>>>>
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
Please, point to the paragraph in the specification of the X86
language that says that a two cycle recursion should be aborted
after one cycle.
Claiming that the abort is related to the x86 language is
apparently wilfully incorrect.
I am not going to show you the trace of the Peano axioms
that prove the 2 + 3 = 5, if you disagree you are a liar
or an ignoramus.
This change of subject does not hide that your claim that the x86
language proves your claim is incorrect as a verified fact.
So you opted for liar then:
_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]
DDD correctly emulated by HHH calls an emulated HHH(DDD)
that emulates DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
HHH aborts after two cycles.
That is not what I said. I will make in more clear.
DDD is correctly emulated by HHH which calls an emulated HHH(DDD)
to repeat this process an endless number of times until aborted
or out-of-memory error.
On 7/3/2024 12:51 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 18:03 schreef olcott:
_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]
DDD is correctly emulated by HHH which calls an emulated HHH(DDD)Anyone knowing the x86 language knows that a program cannot be
to repeat this process an endless number of times until aborted
or out-of-memory error.
programmed to do two different things
It cannot do both run out of memory *and* abort.
DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt.
That HHH aborts its
emulation at some point or never aborts its emulation
cannot possibly change this.
So make up your mind. What does it do?
And what does "endless number of times until aborted" mean? Does it
abort after an infinite number of steps?
Make clear what you mean. After how many cycles is the simulation
aborted?
On 7/3/2024 1:25 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 19:58 schreef olcott:
On 7/3/2024 12:51 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 18:03 schreef olcott:
_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]
DDD is correctly emulated by HHH which calls an emulated HHH(DDD)Anyone knowing the x86 language knows that a program cannot be
to repeat this process an endless number of times until aborted
or out-of-memory error.
programmed to do two different things
It cannot do both run out of memory *and* abort.
DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt.
Exactly! Well done! This proves that HHH cannot possibly correctly
simulate itself. If it aborts, it does so one cycle too soon.
My system of reasoning could be used to make a chatbot
that would make all the propagandists look foolish even
to themselves. The alternative is the destruction of the
planet to earn a couple of more bucks.
This is not some little game that can be played for
trollish sadism. It has consequences.
On 7/3/2024 1:46 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 20:37 schreef olcott:
On 7/3/2024 1:25 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 19:58 schreef olcott:
On 7/3/2024 12:51 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 18:03 schreef olcott:
_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]
DDD is correctly emulated by HHH which calls an emulated HHH(DDD) >>>>>>> to repeat this process an endless number of times until abortedAnyone knowing the x86 language knows that a program cannot be
or out-of-memory error.
programmed to do two different things
It cannot do both run out of memory *and* abort.
DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt.
Exactly! Well done! This proves that HHH cannot possibly correctly
simulate itself. If it aborts, it does so one cycle too soon.
My system of reasoning could be used to make a chatbot
that would make all the propagandists look foolish even
to themselves. The alternative is the destruction of the
planet to earn a couple of more bucks.
This is not some little game that can be played for
trollish sadism. It has consequences.
I appreciate this motivation, but it does not help to make the
simulation correct. Better try something that can help, instead of
spoiling your time with something that does not work as you expected.
That you lie about how it works does not mean it doesn't work.
On 7/3/2024 2:15 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 20:59 schreef olcott:
On 7/3/2024 1:46 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 20:37 schreef olcott:
On 7/3/2024 1:25 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 19:58 schreef olcott:
On 7/3/2024 12:51 PM, Fred. Zwarts wrote:
Op 03.jul.2024 om 18:03 schreef olcott:
_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]
DDD is correctly emulated by HHH which calls an emulated HHH(DDD) >>>>>>>>> to repeat this process an endless number of times until aborted >>>>>>>>> or out-of-memory error.Anyone knowing the x86 language knows that a program cannot be >>>>>>>> programmed to do two different things
It cannot do both run out of memory *and* abort.
DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt.
Exactly! Well done! This proves that HHH cannot possibly correctly >>>>>> simulate itself. If it aborts, it does so one cycle too soon.
My system of reasoning could be used to make a chatbot
that would make all the propagandists look foolish even
to themselves. The alternative is the destruction of the
planet to earn a couple of more bucks.
This is not some little game that can be played for
trollish sadism. It has consequences.
I appreciate this motivation, but it does not help to make the
simulation correct. Better try something that can help, instead of
spoiling your time with something that does not work as you expected.
That you lie about how it works does not mean it doesn't work.
You are too soon with the words lie and liar. It does not contribute
to a honest discussion.
That you hope that it works, does not mean that it works, even when
your hope is based on an appreciated motivation.
You are essentially disagreeing with arithmetic.
There is an arithmetic to the meaning of words
and to the behavior of x86 code.
When I say 2 + 3 = 5 you are not free to disagree
without big a liar. As soon as you disagree THAT MAKES YOU A LIAR
On 7/3/2024 1:41 AM, Mikko wrote:
On 2024-07-02 18:43:35 +0000, olcott said:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
It is still true that the xemantics of the x86
language define the behavior of a set of bytes,
as the behavior when you ACTUALLY RUN THEM,
and nothing else.
_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]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
It is your HHH so you should know whether it returns. Others may
have wrong impression about it if they have trusted your lies.
I have never lied about this.
At least you have claimed more than proven.
_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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE
THAT YOU REMAIN WILLFULLY IGNORANT OF SEMANTICS OF
THE X86 LANGUAGE DOES NOT MEAN IT HAS NOT BEEN PROVEN.
As long as no proof is shown it is not proven.
The proof is self-evident for anyone knowing the x86 language.
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly >>>>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even >>>>>>>>>>> though the semantics of the x86 language disagrees.
HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH to reachDDD correctly emulated by HHH calls an emulated HHH(DDD) that emulatesBut HHH aborts, so the cycle does end.
DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
its own ret instruction then DDD never halts even when its stops running because its emulation was aborted.
On 7/3/2024 10:59 AM, Fred. Zwarts wrote:„An endless number of times until aborted” in this case is 2.
Op 03.jul.2024 om 15:21 schreef olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard thinks that he can get away with disagreeing with this >>>>>>>>>>> verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator HHH >>>>>>>>>>> cannot possibly return.
It is your HHH so you should know whether it returns. Others >>>>>>>>>> may have wrong impression about it if they have trusted your >>>>>>>>>> lies.
I have never lied about this.
At least you have claimed more than proven.
So you opted for liar then:This change of subject does not hide that your claim that the x86I am not going to show you the trace of the Peano axioms that provePlease, point to the paragraph in the specification of the X86IT IS PROVEN BY THE SEMANTICS OF THE X86 LANGUAGE THAT YOU REMAIN >>>>>>> WILLFULLY IGNORANT OF SEMANTICS OF THE X86 LANGUAGE DOES NOT MEAN >>>>>>> IT HAS NOT BEEN PROVEN.DDD is correctly emulated by HHH which calls an emulated
HHH(DDD) to repeat the process until aborted.
The correctness remain unproven.
language that says that a two cycle recursion should be aborted
after one cycle.
Claiming that the abort is related to the x86 language is
apparently wilfully incorrect.
the 2 + 3 = 5, if you disagree you are a liar or an ignoramus.
language proves your claim is incorrect as a verified fact.
DDD correctly emulated by HHH calls an emulated HHH(DDD)HHH aborts after two cycles.
that emulates DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
That is not what I said. I will make in more clear.
DDD is correctly emulated by HHH which calls an emulated HHH(DDD)
to repeat this process an endless number of times until aborted or out-of-memory error.
On 6/30/2024 7:13 PM, Richard Damon wrote:Running out of memory is only a physical constraint of no concern
On 6/30/24 8:00 PM, olcott wrote:
But it does, just after H gives up its simulation.
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
You have even show that with a simulation.
DDD correctly emulated by HHH calls an emulated HHH(DDD)
that emulates its own DDD that calls an emulated HHH(DDD)
that is either aborted at some point never returning or hits
out-of-memory error never returning
On 7/4/2024 5:15 AM, joes wrote:What x86 semantics say that HHH can’t return?
Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly >>>>>>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even >>>>>>>>>>>>> though the semantics of the x86 language disagrees.
Yes, and nothing else. So when HHH returns, so does DDD.By definition DDD calls its simulator.HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH to reachDDD correctly emulated by HHH calls an emulated HHH(DDD) thatBut HHH aborts, so the cycle does end.
emulates DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
its own ret instruction then DDD never halts even when its stops
running because its emulation was aborted.
On 7/4/2024 8:26 AM, joes wrote:Hello?
Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:
On 7/4/2024 5:15 AM, joes wrote:What x86 semantics say that HHH can’t return?
Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly >>>>>>>>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns >>>>>>>>>>>>>>> even though the semantics of the x86 language disagrees.
Why not? Clearly HHH halts. Does it not return or what?*Machine address 00002174 of DDD is never reached*Yes, and nothing else. So when HHH returns, so does DDD.By definition DDD calls its simulator.HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH toDDD correctly emulated by HHH calls an emulated HHH(DDD) thatBut HHH aborts, so the cycle does end.
emulates DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
reach its own ret instruction then DDD never halts even when its
stops running because its emulation was aborted.
On 7/4/2024 8:26 AM, joes wrote:
Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:
On 7/4/2024 5:15 AM, joes wrote:What x86 semantics say that HHH can’t return?
Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD correctly >>>>>>>>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even >>>>>>>>>>>>>>> though the semantics of the x86 language disagrees.
Yes, and nothing else. So when HHH returns, so does DDD.By definition DDD calls its simulator.HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH to reach >>>>> its own ret instruction then DDD never halts even when its stopsDDD correctly emulated by HHH calls an emulated HHH(DDD) thatBut HHH aborts, so the cycle does end.
emulates DDD that calls an emulated HHH(DDD)
in a cycle that cannot end unless aborted.
running because its emulation was aborted.
You simply lack sufficient technical competence of these things
*Machine address 00002174 of DDD is never reached*
I am using an x86 emulator with decades of development effort.
_DDD()
[00002163] 55 push ebp
[00002164] 8bec mov ebp,esp
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
_main()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6863210000 push 00002163
[0000218b] e833f4ffff call 000015c3
[00002190] 83c404 add esp,+04
[00002193] 33c0 xor eax,eax
[00002195] 5d pop ebp
[00002196] c3 ret
Size in bytes:(0020) [00002196]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002183][001037dd][00000000] 55 push ebp [00002184][001037dd][00000000] 8bec mov ebp,esp [00002186][001037d9][00002163] 6863210000 push 00002163 [0000218b][001037d5][00002190] e833f4ffff call 000015c3
New slave_stack at:103881 ; *create a different process context*
Begin Local Halt Decider Simulation Execution Trace Stored at:113889
[00002163][00113879][0011387d] 55 push ebp [00002164][00113879][0011387d] 8bec mov ebp,esp [00002166][00113875][00002163] 6863210000 push 00002163 ; push DDD [0000216b][00113871][00002170] e853f4ffff call 000015c3 ; call HHH(DDD)
New slave_stack at:14e2a9 ; *create a different process context*
[00002163][0015e2a1][0015e2a5] 55 push ebp [00002164][0015e2a1][0015e2a5] 8bec mov ebp,esp [00002166][0015e29d][00002163] 6863210000 push 00002163 ; push DDD [0000216b][0015e299][00002170] e853f4ffff call 000015c3 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002190][001037dd][00000000] 83c404 add esp,+04 [00002193][001037dd][00000000] 33c0 xor eax,eax [00002195][001037e1][00000018] 5d pop ebp [00002196][001037e5][00000000] c3 ret
Number of Instructions Executed(10066) == 150 Pages
On 7/4/2024 10:06 AM, joes wrote:What semantics am I disagreeing with? Doesn’t HHH halt?
Am Thu, 04 Jul 2024 08:41:22 -0500 schrieb olcott:
On 7/4/2024 8:26 AM, joes wrote:Hello?
Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:
On 7/4/2024 5:15 AM, joes wrote:What x86 semantics say that HHH can’t return?
Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said:
Richard just said that he affirms that when DDD >>>>>>>>>>>>>>>>> correctly simulated by HHH calls HHH(DDD) that this call >>>>>>>>>>>>>>>>> returns even though the semantics of the x86 language >>>>>>>>>>>>>>>>> disagrees.
The semantics of the x86 language proves that DDD correctly emulated byWhy not? Clearly HHH halts. Does it not return or what?*Machine address 00002174 of DDD is never reached*Yes, and nothing else. So when HHH returns, so does DDD.By definition DDD calls its simulator.HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH to >>>>>>> reach its own ret instruction then DDD never halts even when its >>>>>>> stops running because its emulation was aborted.DDD correctly emulated by HHH calls an emulated HHH(DDD) that >>>>>>>>> emulates DDD that calls an emulated HHH(DDD)But HHH aborts, so the cycle does end.
in a cycle that cannot end unless aborted.
HHH cannot possibly reach its own machine address 00002183.
On 7/4/2024 11:26 AM, joes wrote:Apparently you only read the bottom.
Am Thu, 04 Jul 2024 11:03:09 -0500 schrieb olcott:
On 7/4/2024 10:06 AM, joes wrote:
Am Thu, 04 Jul 2024 08:41:22 -0500 schrieb olcott:
On 7/4/2024 8:26 AM, joes wrote:Hello?
Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:
On 7/4/2024 5:15 AM, joes wrote:What x86 semantics say that HHH can’t return?
Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
Richard just said that he affirms that when DDD >>>>>>>>>>>>>>>>>>> correctly simulated by HHH calls HHH(DDD) that this >>>>>>>>>>>>>>>>>>> call returns even though the semantics of the x86 >>>>>>>>>>>>>>>>>>> language disagrees.
The execution environment should not make any difference.The DDD correctly emulated by HHH in its own process context cannotWhat semantics am I disagreeing with? Doesn’t HHH halt?The semantics of the x86 language proves that DDD correctly emulatedWhy not? Clearly HHH halts. Does it not return or what?*Machine address 00002174 of DDD is never reached*Yes, and nothing else. So when HHH returns, so does DDD.By definition DDD calls its simulator.HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH to >>>>>>>>> reach its own ret instruction then DDD never halts even when its >>>>>>>>> stops running because its emulation was aborted.DDD correctly emulated by HHH calls an emulated HHH(DDD) that >>>>>>>>>>> emulates DDD that calls an emulated HHH(DDD)But HHH aborts, so the cycle does end.
in a cycle that cannot end unless aborted.
by HHH cannot possibly reach its own machine address 00002183.
possibly halt even if another entirely different instance of DDD does
halt.
On 7/4/2024 11:26 AM, joes wrote:
Am Thu, 04 Jul 2024 11:03:09 -0500 schrieb olcott:
On 7/4/2024 10:06 AM, joes wrote:What semantics am I disagreeing with? Doesn’t HHH halt?
Am Thu, 04 Jul 2024 08:41:22 -0500 schrieb olcott:
On 7/4/2024 8:26 AM, joes wrote:Hello?
Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:
On 7/4/2024 5:15 AM, joes wrote:What x86 semantics say that HHH can’t return?
Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:
On 7/3/2024 9:39 AM, joes wrote:I repeat.
Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb olcott:
On 7/3/2024 3:26 AM, Fred. Zwarts wrote:Which semantics?
Op 02.jul.2024 om 21:48 schreef olcott:
On 7/2/2024 2:22 PM, Fred. Zwarts wrote:
Op 02.jul.2024 om 20:43 schreef olcott:
On 7/2/2024 1:59 AM, Mikko wrote:
On 2024-07-01 12:44:57 +0000, olcott said:
On 7/1/2024 1:05 AM, Mikko wrote:
On 2024-06-30 17:18:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
Richard just said that he affirms that when DDD >>>>>>>>>>>>>>>>>>> correctly simulated by HHH calls HHH(DDD) that this call >>>>>>>>>>>>>>>>>>> returns even though the semantics of the x86 language >>>>>>>>>>>>>>>>>>> disagrees.
The semantics of the x86 language proves that DDD correctly emulated byWhy not? Clearly HHH halts. Does it not return or what?*Machine address 00002174 of DDD is never reached*Yes, and nothing else. So when HHH returns, so does DDD.By definition DDD calls its simulator.HHH halts by definition. Why can’t DDD?As long as it is impossible for DDD correctly emulated by HHH to >>>>>>>>> reach its own ret instruction then DDD never halts even when its >>>>>>>>> stops running because its emulation was aborted.DDD correctly emulated by HHH calls an emulated HHH(DDD) that >>>>>>>>>>> emulates DDD that calls an emulated HHH(DDD)But HHH aborts, so the cycle does end.
in a cycle that cannot end unless aborted.
HHH cannot possibly reach its own machine address 00002183.
The DDD correctly emulated by HHH in its own process
context cannot possibly halt even if another entirely
different instance of DDD does halt.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 429 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 117:50:48 |
| Calls: | 9,056 |
| Calls today: | 3 |
| Files: | 13,396 |
| Messages: | 6,016,625 |