On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>Your problem is you don't understand the meaning of the words you are >>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>> conclusion that the Halting Problem is undecidable, we argue that the >>>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>>> we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>> making assumptions about a decider's domain that do not hold under a >>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
On 7/21/2025 9:20 PM, Richard Damon wrote:As usual incorrect claims without evidence.
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>Your problem is you don't understand the meaning of the words you are >>>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that >>>>>>> the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
On 7/21/2025 9:20 PM, Richard Damon wrote:
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>Your problem is you don't understand the meaning of the words you are >>>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that >>>>>>> the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
The presumption that the behavior specified by the machine
description of a machine is always exactly the same as the
behavior of the directly executed machine has one exception.
When the input to the decider calls its own simulating halt
decider this causes recursive simulation. This changes the
behavior. The direct execution halts and the correctly simulated
machine cannot possibly halt.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
When Ĥ is applied to ⟨Ĥ⟩ and embedded_H is a simulating
partial halt decider
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Because ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
would remain stuck in recursive simulation unless
embedded_H aborts this simulation embedded_H is
correct to transition to its own final state of Ĥ.qn.
Op 22.jul.2025 om 06:17 schreef olcott:
On 7/21/2025 9:20 PM, Richard Damon wrote:As usual incorrect claims without evidence.
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>Your problem is you don't understand the meaning of the words you >>>>>>> are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>> conclusion that the Halting Problem is undecidable, we argue
that the
conventional proof fails to establish this conclusion due to a >>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>>>> making assumptions about a decider's domain that do not hold
under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
Nobody requires the halt decider to report on another direct execution.
The halt decider must decide on its input. In this case the input
specifies a DD that calls a HHH that aborts and returns, so the input specifies a halting program.
That HHH fails to see that does not change the specification.--
That this input specifies a halting program, is proven in many ways, of which the direct execution is only one of them.
On 7/22/25 12:17 AM, olcott wrote:
On 7/21/2025 9:20 PM, Richard Damon wrote:
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>Your problem is you don't understand the meaning of the words you >>>>>>> are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>> conclusion that the Halting Problem is undecidable, we argue
that the
conventional proof fails to establish this conclusion due to a >>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>>>> making assumptions about a decider's domain that do not hold
under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
If it seems "self-evident" to you, that just shows how warped you ideas
are of what the field means.
On 7/22/2025 3:45 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 06:17 schreef olcott:
On 7/21/2025 9:20 PM, Richard Damon wrote:As usual incorrect claims without evidence.
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>>Your problem is you don't understand the meaning of the words >>>>>>>> you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue >>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>> conflating
the behavior of encoded simulations with direct execution, and >>>>>>>>> from
making assumptions about a decider's domain that do not hold >>>>>>>>> under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
Nobody requires the halt decider to report on another direct execution.
counter-factual
The *domain of this problem is to be taken as the*
*set of all Turing machines* [WRONG] and all w;
that is, we are
looking for a single Turing machine that, given the
description of an arbitrary M and w, will predict
whether or not the computation of M applied to w will halt. https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
The halt decider must decide on its input. In this case the input
specifies a DD that calls a HHH that aborts and returns, so the input
specifies a halting program.
The simulated DDD that calls a simulated HHH(DDD)
never aborts or returns.
The directly executed HHH aborts its simulation
of DDD which in turn kills the whole simulation
process that includes the simulated HHH.
That HHH fails to see that does not change the specification.
That this input specifies a halting program, is proven in many ways,
of which the direct execution is only one of them.
On 7/22/2025 6:39 AM, Richard Damon wrote:
On 7/22/25 12:17 AM, olcott wrote:
On 7/21/2025 9:20 PM, Richard Damon wrote:
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>>Your problem is you don't understand the meaning of the words >>>>>>>> you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue >>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>> conflating
the behavior of encoded simulations with direct execution, and >>>>>>>>> from
making assumptions about a decider's domain that do not hold >>>>>>>>> under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
If it seems "self-evident" to you, that just shows how warped you
ideas are of what the field means.
In this field it is common knowledge that no Turing machine
decider ever takes another directly executed Turing machine
as its input.
This means that Linz is wrong that machine M
should report on the behavior of its own direct
execution as his words state below.
WM is the machine description of M
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
q0 WM ⊢* Ĥq0 Wm WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.
TM's can only compute the mapping from inputs and M
is not an input.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
On 7/22/2025 3:45 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 06:17 schreef olcott:
On 7/21/2025 9:20 PM, Richard Damon wrote:As usual incorrect claims without evidence.
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>>Your problem is you don't understand the meaning of the words >>>>>>>> you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue >>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>> conflating
the behavior of encoded simulations with direct execution, and >>>>>>>>> from
making assumptions about a decider's domain that do not hold >>>>>>>>> under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
Nobody requires the halt decider to report on another direct execution.
counter-factual
The *domain of this problem is to be taken as the*
*set of all Turing machines* [WRONG] and all w;
that is, we are
looking for a single Turing machine that, given the
description of an arbitrary M and w, will predict
whether or not the computation of M applied to w will halt. https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
The halt decider must decide on its input. In this case the input
specifies a DD that calls a HHH that aborts and returns, so the input
specifies a halting program.
The simulated DDD that calls a simulated HHH(DDD)
never aborts or returns.
The directly executed HHH aborts its simulationHHH aborts before it reaches the final halt state. There is nothing in
of DDD which in turn kills the whole simulation
process that includes the simulated HHH.
Op 22.jul.2025 om 18:09 schreef olcott:
On 7/22/2025 3:45 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 06:17 schreef olcott:
On 7/21/2025 9:20 PM, Richard Damon wrote:As usual incorrect claims without evidence.
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem >>>>>>>>>> ProofYour problem is you don't understand the meaning of the words >>>>>>>>> you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of >>>>>>>>>> the
undecidability of the Halting Problem. While we do not dispute >>>>>>>>>> the
conclusion that the Halting Problem is undecidable, we argue >>>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>>> conflating
the behavior of encoded simulations with direct execution, and >>>>>>>>>> from
making assumptions about a decider's domain that do not hold >>>>>>>>>> under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your
HHH(DDD) returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
Nobody requires the halt decider to report on another direct execution.
counter-factual
As usual incorrect claims without evidence.
The *domain of this problem is to be taken as the*
*set of all Turing machines* [WRONG] and all w;
that is, we are
looking for a single Turing machine that, given the
description of an arbitrary M and w, will predict
whether or not the computation of M applied to w will halt.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Note the 'given the description of an arbitrary M". It does not say
'given an arbitrary M'. The word 'description' makes your claim counter- factual.
The halt decider must decide on its input. In this case the input
specifies a DD that calls a HHH that aborts and returns, so the input
specifies a halting program.
The simulated DDD that calls a simulated HHH(DDD)
never aborts or returns.
But the HHH called by DDD is programmed to abort after a finite
recursion. The behaviour of DDD depends on the behaviour of HHH. When
HHH returns with a value of 0, DDD reaches the final halt state.
That is what is specified. That is what a correct simulation would see.
--
The directly executed HHH aborts its simulation
of DDD which in turn kills the whole simulation
process that includes the simulated HHH.
HHH aborts before it reaches the final halt state. There is nothing in
the simulation that shows that there is no final halt state. In fact,
HHH ignores the conditional branch instructions during the simulation,
which could tell it that there is a final halt state.
Nowhere there is a reference to direct execution. It is only the
semantics of the x86 language that tells enough to prove the halting behaviour of the program specified in the input. That HHH fails to
simulate he input up to the end, does not change the specification.
On 7/23/2025 3:20 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 18:09 schreef olcott:
On 7/22/2025 3:45 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 06:17 schreef olcott:counter-factual
On 7/21/2025 9:20 PM, Richard Damon wrote:As usual incorrect claims without evidence.
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem >>>>>>>>>>> ProofYour problem is you don't understand the meaning of the words >>>>>>>>>> you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>> of the
undecidability of the Halting Problem. While we do not
dispute the
conclusion that the Halting Problem is undecidable, we argue >>>>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>> fundamental misapplication of Turing machine semantics. >>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>>>> conflating
the behavior of encoded simulations with direct execution, >>>>>>>>>>> and from
making assumptions about a decider's domain that do not hold >>>>>>>>>>> under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it
should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your
HHH(DDD) returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
Nobody requires the halt decider to report on another direct execution. >>>
As usual incorrect claims without evidence.
The *domain of this problem is to be taken as the*
*set of all Turing machines* [WRONG] and all w;
The domain of the problem is not *set of all Turing machines*
it is the *set of all finite string Turing machine descriptions*
that is, we are
looking for a single Turing machine that, given the
description of an arbitrary M and w, will predict
whether or not the computation of M applied to w will halt.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Note the 'given the description of an arbitrary M". It does not say
'given an arbitrary M'. The word 'description' makes your claim
counter- factual.
The halt decider must decide on its input. In this case the input
specifies a DD that calls a HHH that aborts and returns, so the
input specifies a halting program.
The simulated DDD that calls a simulated HHH(DDD)
never aborts or returns.
But the HHH called by DDD is programmed to abort after a finite
recursion. The behaviour of DDD depends on the behaviour of HHH. When
HHH returns with a value of 0, DDD reaches the final halt state.
That is what is specified. That is what a correct simulation would see.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
*This is a verified fact*
*Any disagreement proves lack of understanding*
The fact that no DDD emulated by HHH according to the
semantics of the x86 language can possibly reach its
own simulated "ret" instruction final halt state proves
that DDD specifies non-halting behavior.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 148:12:41 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
33 files (6,120K bytes) |
| Messages: | 2,410,932 |