XPost: sci.logic

Op 01.Jul.2024 OM 17:20 screech Wolcott:

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

But it does not correctly determine that the simulated D would never
stop running. Your seem to be incompetent to understand that a C
program, or x86 language that specifies N cycles of recursive simulation
does stop after those cycles are all simulated, even when simulated
correctly.

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.

void Finite_Recursion (nit N) {
if (N > 0) Finite_Recursion (N - 1);
}

HEH, aborting after N cycles of recursive simulation, when simulating
itself, is equivalent to Finite_Recursion, not to Infinite_Recursion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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, continues, since it
MUST due the semantics of the x86 instruction set.

You just are stuck in your world of fantasy, and have lost contact with REALITY.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 7/1/24 9:32 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, 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*

Nope, that CAN'T be the definition of the "behvior of the Input" but of
the behavior of the "input processed by this machine". "Behavior" is a
term used on MACHINES (so in the above case, the machine is the DECIDER,
not the input). When you talk about the "behavior of the input" that
needs to represent the behavior of the machine the input represents.

You just don't seem to understand the basics of the field, because you
your enforce ignorance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

Your definition doesn't work, as the "Behavior of the Input" isn't a
function of just the input, but also of the decider.

It is exactly like asking "What is the sum of two plus?"

The emulation only REVEALS the behavior to the decider, not create it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 7/1/24 10:21 PM, olcott wrote:

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.

No, because the static string represents a program that interpreter can determine the behavior of.

It seems you don't understand the concept of representation.

Perhaps because you never actually studied real computer science, but
were only a hack programmer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-01 12:49:54 +0000, olcott said:

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.

The behaviour specified by DDD is whatever it is, and does not depend on whether it is ever emulated or executed or analyzed.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Once aborted the DDD emulated by HHH immediately stops.

No, it does not. DDD stops when it executes the ret instruction at 2183
or the function at 15d2 calls exit.

At no point in this emulation does the call from DDD
correctly emulated by HHH to HHH(DDD) ever return.

Everyone who knows x86 machine or assembly language can see that
DDD terminates normally if and only if HHH terminates normally.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/2/24 2:43 PM, olcott wrote:

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.

Nope, The semantics of the x86 language say every DDD that calls an
HHH(DDD) that ever returns to main, will eventually return, even if the
HHH can never see that return.

YOU are the idiot that doesn't beleive the facts before his eyes because
he refuses to look.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

I am so sorry for you. You are crying for help, but when serious people
are trying to help you, yo don't want to think about their help.
In this way you will never learn and never make any progress. That makes
it a sad story.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, 01 Jul 2024 20:42:58 -0500 schrieb olcott:

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'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.

The input describes a program that doesn’t stop when run, regardless
whether you actually run it (in part or whole).

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, 01 Jul 2024 20:32:18 -0500 schrieb olcott:

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.

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.

Defined that way, there is no notion of the input halting or not AT ALL.
If you abort, you are not simulating the input, because it doesn’t contain
an abort.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

It is your HHH so you should know whether it returns. Others may >>>>>>>> have wrong impression about it if they have trusted your lies.

If it returns, it doesn’t need to be aborted.

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.

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.

It is very easy to show.

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.

But HHH aborts, so the cycle does end.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 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.

HHH aborts after two cycles. So, its simulation needs only two cycles to
make it return. However, HHH is not able to simulate two cycles.
Therefore, it aborts one cycle too soon. This shows that HHH cannot
correctly simulate itself.
The 'unless' phrase is misleading, because it suggests that HHH will not
abort. But dreaming of a HHH that does not abort is irrelevant. HHH
*does* abort. Therefore, the simulation of HHH does not need to be
aborted. This is shown to be correct when HHH is simulated by a
simulator that does not abort too soon.
Therefore, you only prove that HHH cannot be simulated correctly by itself. Don't start talking about the x86 language, because the x86 language
does not define when an abort should occur.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 03.jul.2024 om 18:03 schreef olcott:

On 7/3/2024 10:59 AM, Fred. Zwarts wrote:

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 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.

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.

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.
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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

That HHH aborts its
emulation at some point or never aborts its emulation
cannot possibly change this.

Indeed, an abort does not make the simulation correct and an infinite simulation is not correct either.

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 03.jul.2024 om 21:23 schreef olcott:

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

Irrelevant. I do not deny that 2+3=5.
But if you claim that the x86 language says that a two cycle recursion
must be aborted, then I know who is ignoring the truth.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-03 13:17:48 +0000, olcott said:

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.

Doesn't matter. As long as no proof is shown your claim is unproven.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 03 Jul 2024 11:03:29 -0500 schrieb olcott:

On 7/3/2024 10:59 AM, Fred. Zwarts wrote:

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.

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 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.

„An endless number of times until aborted” in this case is 2.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, 30 Jun 2024 19:27:50 -0500 schrieb olcott:

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?

But it does, just after H gives up its simulation.
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

Running out of memory is only a physical constraint of no concern
to the theoretical behaviour.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:

On 7/4/2024 5:15 AM, joes wrote:

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

What x86 semantics say that HHH can’t return?

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

By definition DDD calls its simulator.

Yes, and nothing else. So when HHH returns, so does DDD.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, 04 Jul 2024 08:41:22 -0500 schrieb olcott:

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:

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

What x86 semantics say that HHH can’t return?

Hello?

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

By definition DDD calls its simulator.

Yes, and nothing else. So when HHH returns, so does DDD.

*Machine address 00002174 of DDD is never reached*

Why not? Clearly HHH halts. Does it not return or what?

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/4/24 9:41 AM, olcott wrote:

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:

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

What x86 semantics say that HHH can’t return?

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

By definition DDD calls its simulator.

Yes, and nothing else. So when HHH returns, so does DDD.

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

Why does main calling HHH create a new "process context" that isn't what
CALL Instructions do.

SO, you simulation is clearly not correct, or not correctly interpreted.

The trace of the program should have continued showing the PROGRAMs
execution path.

Yes, at some point that HHH will creeate a virtual process context to
simulate that you show below, but that means that the below trace is no
longer a trace of main calling HHH, but of the simulation of HHH.

[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*

And calling HHH(DDD) doesn't create a new process context either, it
calls the function HHH which is what should be traced here.

Yes, your simulated HHH will create within itself a new virtual process
context and this is now a THIRD DISTINCT SIMULATION which is INCORRECTLY
shown as part of the simulation of the above two different simulations.

THAT IS AN ERROR.

[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

So, by playing the shell games and mixing up three different program
context that exists you confused yourself in beleiving your own lies.

The simulation of the second program context was shown to be terminated,
but that same program context, when fully simulated will show the same
sort of behavior, of it aborting its simulation of the third program
context, and returning, and thus the CORRECT behavior of the second
context is that it will be finite and return.

Your problem is you don't understand that simulation doesn't define the behavior of the input, it reveals that part of it that it does. The full behavior of the input is defined by what the program it represents does,
which is what a COMPLETE simulation of it will show.

This is just more of your confusion of Truth and Knowledge which has
made your logic system broken.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

Am Thu, 04 Jul 2024 07:46:15 -0500 schrieb olcott:

On 7/4/2024 5:15 AM, joes wrote:

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

What x86 semantics say that HHH can’t return?

Hello?

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

By definition DDD calls its simulator.

Yes, and nothing else. So when HHH returns, so does DDD.

*Machine address 00002174 of DDD is never reached*

Why not? Clearly HHH halts. Does it not return or what?

The semantics of the x86 language proves that DDD correctly emulated by
HHH cannot possibly reach its own machine address 00002183.

What semantics am I disagreeing with? Doesn’t HHH halt?

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, 04 Jul 2024 11:31:08 -0500 schrieb olcott:

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:

Am Thu, 04 Jul 2024 08:41:22 -0500 schrieb olcott:

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:

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

What x86 semantics say that HHH can’t return?

Hello?

Apparently you only read the bottom.

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

By definition DDD calls its simulator.

Yes, and nothing else. So when HHH returns, so does DDD.

*Machine address 00002174 of DDD is never reached*

Why not? Clearly HHH halts. Does it not return or what?

The semantics of the x86 language proves that DDD correctly emulated
by HHH cannot possibly reach its own machine address 00002183.

What semantics am I disagreeing with? Doesn’t HHH halt?

The DDD correctly emulated by HHH in its own process context cannot
possibly halt even if another entirely different instance of DDD does
halt.

The execution environment should not make any difference.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/4/24 12:31 PM, olcott wrote:

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:

Am Thu, 04 Jul 2024 08:41:22 -0500 schrieb olcott:

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:

Am Wed, 03 Jul 2024 09:45:57 -0500 schrieb olcott:

On 7/3/2024 9:39 AM, joes wrote:

Am Wed, 03 Jul 2024 08:21:40 -0500 schrieb 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 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.

Which semantics?

I repeat.

What x86 semantics say that HHH can’t return?

Hello?

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.

But HHH aborts, so the cycle does end.

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.

HHH halts by definition. Why can’t DDD?

By definition DDD calls its simulator.

Yes, and nothing else. So when HHH returns, so does DDD.

*Machine address 00002174 of DDD is never reached*

Why not? Clearly HHH halts. Does it not return or what?

The semantics of the x86 language proves that DDD correctly emulated by
HHH cannot possibly reach its own machine address 00002183.

What semantics am I disagreeing with? Doesn’t HHH halt?

The DDD correctly emulated by HHH in its own process
context cannot possibly halt even if another entirely
different instance of DDD does halt.

Which just means that HHH can not emulate DDD to a final state.

That doesn't mean that the DDD being emulated can't be a program that
reaches a final state, just that HHH doesn't emulate it far enough.

Partial Emulaitons do not directly provide evidence of future behavior,
only the behavior of the steps that were emulated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)