On 2/27/25 10:29 AM, olcott wrote:

On 2/27/2025 3:26 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 00:09 schreef olcott:

On 2/26/2025 3:52 PM, joes wrote:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081
In line 1137, we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded,
&code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

We then pass the saved flag in line 1143:
if (Decide_Halting_HH(&Aborted, &execution_trace, &decoded,
code_end, End_Of_Code, &master_state, &slave_state, &slave_stack,
Root)),
defined in line 1030.
Then we get a switch:
1059    if (Root)  // Master UTM halt decider
Line 1070 is then conditionally skipped:
Needs_To_Be_Aborted_HH((Decoded_Line_Of_Code*)**execution_trace);
defined in line 1012, which (on a jmp or call instruction) calls
u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code* execution_trace, >>>>                                   Decoded_Line_Of_Code *current)
in line 964, where the abort logic lives. (It basically triggers
on a call or jump to itself.)

So we only abort depending on the address of the execution trace.
This makes no sense. Why is that?

DD emulated by HHH according to the behavior that the x86
machine code of DD cannot possibly terminate normally thus
HHH is infallibly correct to report that this DD emulated
by HHH (not any other DD in the whole freaking universe)
is not-terminating.

No, it is correct to report that HHH is unable to correctly simulate
this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

BUt there is not infinte recursion because every HHH that would be in
that loop aborts and returns.

It has to, since that is what you code does.

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

On 27/02/2025 21:07, joes wrote:

Am Thu, 27 Feb 2025 18:40:14 +0000 schrieb Mike Terry:

On 27/02/2025 10:06, Mikko wrote:

On 2025-02-26 21:52:31 +0000, joes said:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081 In line 1137,
we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded,
&code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

The variable execution_trace is a pointer to a pointer to a 32 bit
unsigned int. The function Init_Halts_HH may update the pointer
*execution_trace or the number **execution_trace. The special value
0x90909090, when interpreted as a fragment of a program, means four no
operation instructions. That many no operation instructions is not used
in the compiled code so it can be used as a speial value where
otherwise instrunctions generated by the compiler are expected.

Thank you.

Given this design, the inner HHHs must not allocate another
trace table. Also they skip the abort analysis logic, making their
simulated code behaviour different from the outermost HHH.

^

Why 0x90909090? When you look at the HHH code, you probably wonder "WTF
is all this DATA1, DATA2 and related assembler stuff for?" The answer
is it's not really for anything useful! It was just some experiment PO
was conducting at some point to show to himself that the code of HHH
could update itself if it wanted to. The DATA1/DATA2 areas hold the
direct addresses to global data areas like the execution trace table.
PO initialises them with:

So the memory is garbage before and doesn't get updated afterwards?

No, the DATA1/DATA2 memory is part of the program /code/ of HHH, initialised to NOP instructions.
Also there are similar areas in the variation functions HHH1 and so on.

Normally if you're writing C code and you need a static variable you would write e.g.

u32 HHH(ptr P)
{
u32* Aborted;
static u32* execution_trace = NULL; /* <===== */
u32 End_Of_Code;
..
if (execution_trace == NULL)
{ /* first time (outer HHH) */
execution_trace = Allocate (sizeof(Decoded_Line_Of_Code) * 10000);
}
...
}

Done this way, execution_trace is naturally in the program /data/ segment, not the /code/ segment.
Initialising it to NULL is natural and I think the default anyway for static data. PO could
disassemble HHH function without encountering the null bytes as code. But instead he wants the
DATA1 /code/ text to contain the Allocated memory address, and DATA1 is part of the /code/ segment
so he initialises it to NOPs to avoid problems disassembling it. He sets execution_trace to point
to DATA1 introducing an extra level of redirection everywhere it's used, in case you were wondering
about extra * appearing in the code in various places. :) The DATA1 is later updated with the
pointer from Allocate() but that is done indirectly via **execution_trace = ... (note extra *)

Mike.

..and the nop instruction is 0x90, hence the first-through test for
0x90909090.

That was the bit I'm missing.

Why did PO use nop instructions here? Well, he has code elsewhere that
disassembles all the halt7.c functions as part of x86utm.exe output
listing. That code would expect DATA1/DATA2 to contain valid x86
instructions or it would choke. The comments in the code above shows
that he doesn't understand TMs and the concept of code vs data, and the
fact that a TMs code is not on its tape etc. etc. etc.

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

Op 27.feb.2025 om 22:42 schreef olcott:

On 2/27/2025 1:12 PM, Fred. Zwarts wrote:

Op 27.feb.2025 om 16:29 schreef olcott:

On 2/27/2025 3:26 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 00:09 schreef olcott:

On 2/26/2025 3:52 PM, joes wrote:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081
In line 1137, we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded,
&code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

We then pass the saved flag in line 1143:
if (Decide_Halting_HH(&Aborted, &execution_trace, &decoded,
code_end, End_Of_Code, &master_state, &slave_state, &slave_stack,
Root)),
defined in line 1030.
Then we get a switch:
1059    if (Root)  // Master UTM halt decider
Line 1070 is then conditionally skipped:
Needs_To_Be_Aborted_HH((Decoded_Line_Of_Code*)**execution_trace);
defined in line 1012, which (on a jmp or call instruction) calls
u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code*
execution_trace,
                                  Decoded_Line_Of_Code *current)
in line 964, where the abort logic lives. (It basically triggers
on a call or jump to itself.)

So we only abort depending on the address of the execution trace.
This makes no sense. Why is that?

DD emulated by HHH according to the behavior that the x86
machine code of DD cannot possibly terminate normally thus
HHH is infallibly correct to report that this DD emulated
by HHH (not any other DD in the whole freaking universe)
is not-terminating.

No, it is correct to report that HHH is unable to correctly simulate
this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

In other words Olcott is dreaming again of an infinite recursion,
where it has been proven by the direct execution that the aborting HHH
has no infinite recursion. It HAS AN END! Dreams are no substitute for
logic.

It is flat out dishonest to change the subject away
from DD emulated by HHH.

It is flat out incorrect to suggest that this DD is a different one.
There is only one finite string, describing only one behaviour.

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

Op 28.feb.2025 om 00:12 schreef olcott:

On 2/27/2025 1:15 PM, Fred. Zwarts wrote:

Op 27.feb.2025 om 19:55 schreef olcott:

On 2/27/2025 3:26 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 00:09 schreef olcott:

On 2/26/2025 3:52 PM, joes wrote:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081
In line 1137, we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded,
&code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

We then pass the saved flag in line 1143:
if (Decide_Halting_HH(&Aborted, &execution_trace, &decoded,
code_end, End_Of_Code, &master_state, &slave_state, &slave_stack,
Root)),
defined in line 1030.
Then we get a switch:
1059    if (Root)  // Master UTM halt decider
Line 1070 is then conditionally skipped:
Needs_To_Be_Aborted_HH((Decoded_Line_Of_Code*)**execution_trace);
defined in line 1012, which (on a jmp or call instruction) calls
u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code*
execution_trace,
                                  Decoded_Line_Of_Code *current)
in line 964, where the abort logic lives. (It basically triggers
on a call or jump to itself.)

So we only abort depending on the address of the execution trace.
This makes no sense. Why is that?

DD emulated by HHH according to the behavior that the x86
machine code of DD cannot possibly terminate normally thus
HHH is infallibly correct to report that this DD emulated
by HHH (not any other DD in the whole freaking universe)
is not-terminating.

No, it is correct to report that HHH is unable to correctly simulate
this halting program up to its end.

That you do not comprehend that infinite recursion
DOES NOT END is your ignorance.

I never said that there is an infinite recursion.

It seems that you simply lack sufficient technical
competence to understand these things.

No rebuttal, only dreams of of something Olcott does not know anything
about. So, not a real contribution to the discussion.
So, try to give a honest answer.

There is no infinite recursion. Neither in the direct execution, nor in
the simulation. It is only in Olcott's dreams of a hypothetical HHH.
Dreams are no substitute for logic.
A finite recursion HAS AN END. Olcott's HHH is unable to reach that end.
That is not a dream, but a verified fact.

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

On 2025-02-27 15:29:31 +0000, olcott said:

On 2/27/2025 3:26 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 00:09 schreef olcott:

On 2/26/2025 3:52 PM, joes wrote:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081
In line 1137, we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded, &code_end, >>>> (u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

We then pass the saved flag in line 1143:
if (Decide_Halting_HH(&Aborted, &execution_trace, &decoded,
code_end, End_Of_Code, &master_state, &slave_state, &slave_stack, Root)), >>>> defined in line 1030.
Then we get a switch:
1059    if (Root)  // Master UTM halt decider
Line 1070 is then conditionally skipped:
Needs_To_Be_Aborted_HH((Decoded_Line_Of_Code*)**execution_trace);
defined in line 1012, which (on a jmp or call instruction) calls
u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code* execution_trace, >>>>                                   Decoded_Line_Of_Code *current)
in line 964, where the abort logic lives. (It basically triggers
on a call or jump to itself.)

So we only abort depending on the address of the execution trace.
This makes no sense. Why is that?

DD emulated by HHH according to the behavior that the x86
machine code of DD cannot possibly terminate normally thus
HHH is infallibly correct to report that this DD emulated
by HHH (not any other DD in the whole freaking universe)
is not-terminating.

No, it is correct to report that HHH is unable to correctly simulate
this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

Do you mean that having no end enables the simulation to the end?

--
Mikko

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

On 2/27/25 9:05 PM, olcott wrote:

On 2/27/2025 7:41 PM, Mike Terry wrote:

On 27/02/2025 21:07, joes wrote:

Am Thu, 27 Feb 2025 18:40:14 +0000 schrieb Mike Terry:

On 27/02/2025 10:06, Mikko wrote:

On 2025-02-26 21:52:31 +0000, joes said:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081 In line 1137, >>>>>> we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded,
&code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

The variable execution_trace is a pointer to a pointer to a 32 bit
unsigned int. The function Init_Halts_HH may update the pointer
*execution_trace or the number **execution_trace. The special value
0x90909090, when interpreted as a fragment of a program, means four no >>>>> operation instructions. That many no operation instructions is not
used
in the compiled code so it can be used as a speial value where
otherwise instrunctions generated by the compiler are expected.

Thank you.

Given this design, the inner HHHs must not allocate another
trace table.  Also they skip the abort analysis logic, making their
simulated code behaviour different from the outermost HHH.

^

Why 0x90909090?  When you look at the HHH code, you probably wonder
"WTF
is all this DATA1, DATA2 and related assembler stuff for?"  The answer >>>> is it's not really for anything useful!  It was just some experiment PO >>>> was conducting at some point to show to himself that the code of HHH
could update itself if it wanted to.  The DATA1/DATA2 areas hold the
direct addresses to global data areas like the execution trace table.
PO initialises them with:

So the memory is garbage before and doesn't get updated afterwards?

No, the DATA1/DATA2 memory is part of the program /code/ of HHH,
initialised to NOP instructions. Also there are similar areas in the
variation functions HHH1 and so on.

Normally if you're writing C code and you need a static variable you
would write e.g.

u32 HHH(ptr P)
{
   u32* Aborted;
   static u32* execution_trace = NULL;  /* <===== */
   u32  End_Of_Code;
   ..
   if (execution_trace == NULL)
   { /* first time (outer HHH) */
     execution_trace = Allocate (sizeof(Decoded_Line_Of_Code) * 10000); >>    }
   ...
}

Done this way, execution_trace is naturally in the program /data/
segment, not the /code/ segment. Initialising it to NULL is natural
and I think the default anyway for static data.  PO could disassemble
HHH function without encountering the null bytes as code.  But instead
he wants the DATA1 /code/ text to contain the Allocated memory
address, and DATA1 is part of the /code/ segment so he initialises it
to NOPs to avoid problems disassembling it.  He sets execution_trace
to point to DATA1 introducing an extra level of redirection everywhere
it's used, in case you were wondering about extra * appearing in the
code in various places.  :)  The DATA1 is later updated with the
pointer from Allocate() but that is done indirectly via
**execution_trace = ... (note extra *)

Mike.

My idea of all of this is that a TM could do this same
sort of thing. The outer TM knows its own tape and
allocates a portion of this tape to slave instance of
itself. Each instance of these TM's thinks that a single
execution_trace belongs to itself alone.

A TM Could not do the same sort of thing, as your "programs" don't meet
the requirements of being actual programs.

YOur problem is you just don't understand what that means, an thus you
think it is ok to just make up lies.

A simulated machine can not know it is being simulated or the simulation
is not correct, because the only information a program can use is what
is in its input.

The simulator doesn't allocate part of its tape for the simulated
version, but creates a "virtual" tape within its tape to encode the
current state.

In any case this is all totally moot until one understands
that DD correctly simulated by HHH and

Which is totally moot as HHH doesn't correctly simulate DD, since it
aborts and returns an answer.

You are just demonstarting your stupidity, thinking that one program can
be doing two different things at once.

Ĥ.q0 ⟨M⟩ ⊢* embedded_H ⟨M⟩ ⟨M⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨M⟩ ⊢* embedded_H ⟨M⟩ ⟨M⟩ ⊢* Ĥ.qn

And if embedded_H doesn't act exactly like H, your input is a lie.

WHich means that your H must be wrong, as it answers yes for a machine
that didn't halt or no for a machine that does halt.

Linz ⟨Ĥ⟩ correctly simulated by Linz Ĥ.embedded_H
specify non terminating behavior to their termination
analyzer partial halt decider.

Nope, because again, if embedded_H goes to n, it did so by not
simulating the input correctly, since it aborted its simulation.

Your mind, because it insists on the existance of a truth fairy to make
your impossible happen, just lies to you that it can do that.

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

On 2025-03-01 01:16:41 +0000, olcott said:

On 2/28/2025 3:16 AM, Mikko wrote:

On 2025-02-27 15:29:31 +0000, olcott said:

No, it is correct to report that HHH is unable to correctly simulate
this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

Do you mean that having no end enables the simulation to the end?

see my new post
DD emulated by HHH cannot possibly terminate normally --- x86 code

In that post:

DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]

When we hypothesize that the code at machine address
0000213c is an x86 emulator then we know that DD
remains stuck in recursive emulation and cannot possibly
reach its own "ret" instruction and terminate normally.

When we add the additional complexity that HHH also
aborts this sequence at some point then every level
of recursive emulation immediately stops. This does
not enable any DD to ever reach its "ret" instruction.

The question remains unanswered. If the author cannot tell what he
means we may assume that he didn't mean anything.

--
Mikko

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

On 2025-03-01 01:46:06 +0000, olcott said:

On 2/28/2025 8:30 AM, Richard Damon wrote:

On 2/27/25 9:05 PM, olcott wrote:

On 2/27/2025 7:41 PM, Mike Terry wrote:

On 27/02/2025 21:07, joes wrote:

Am Thu, 27 Feb 2025 18:40:14 +0000 schrieb Mike Terry:

On 27/02/2025 10:06, Mikko wrote:

On 2025-02-26 21:52:31 +0000, joes said:

Since there is so much talk around, but not really about it,
let's take a look:
https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1081 In line 1137, >>>>>>>> we compute a flag:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded, >>>>>>>> &code_end,
(u32)P, &master_state, &slave_state, &slave_stack);
In line 918, we find it basically checks for the magic number
**execution_trace==0x90909090. What is this unexplained value?

The variable execution_trace is a pointer to a pointer to a 32 bit >>>>>>> unsigned int. The function Init_Halts_HH may update the pointer
*execution_trace or the number **execution_trace. The special value >>>>>>> 0x90909090, when interpreted as a fragment of a program, means four no >>>>>>> operation instructions. That many no operation instructions is not used >>>>>>> in the compiled code so it can be used as a speial value where
otherwise instrunctions generated by the compiler are expected.

Thank you.

Given this design, the inner HHHs must not allocate another
trace table.  Also they skip the abort analysis logic, making their >>>>>> simulated code behaviour different from the outermost HHH.

^

Why 0x90909090?  When you look at the HHH code, you probably wonder "WTF
is all this DATA1, DATA2 and related assembler stuff for?"  The answer >>>>>> is it's not really for anything useful!  It was just some experiment PO >>>>>> was conducting at some point to show to himself that the code of HHH >>>>>> could update itself if it wanted to.  The DATA1/DATA2 areas hold the >>>>>> direct addresses to global data areas like the execution trace table. >>>>>> PO initialises them with:

So the memory is garbage before and doesn't get updated afterwards?

No, the DATA1/DATA2 memory is part of the program /code/ of HHH,
initialised to NOP instructions. Also there are similar areas in the
variation functions HHH1 and so on.

Normally if you're writing C code and you need a static variable you
would write e.g.

u32 HHH(ptr P)
{
   u32* Aborted;
   static u32* execution_trace = NULL;  /* <===== */
   u32  End_Of_Code;
   ..
   if (execution_trace == NULL)
   { /* first time (outer HHH) */
     execution_trace = Allocate (sizeof(Decoded_Line_Of_Code) * 10000);
   }
   ...
}

Done this way, execution_trace is naturally in the program /data/
segment, not the /code/ segment. Initialising it to NULL is natural and >>>> I think the default anyway for static data.  PO could disassemble HHH >>>> function without encountering the null bytes as code.  But instead he >>>> wants the DATA1 /code/ text to contain the Allocated memory address,
and DATA1 is part of the /code/ segment so he initialises it to NOPs to >>>> avoid problems disassembling it.  He sets execution_trace to point to >>>> DATA1 introducing an extra level of redirection everywhere it's used,
in case you were wondering about extra * appearing in the code in
various places.  :)  The DATA1 is later updated with the pointer from >>>> Allocate() but that is done indirectly via **execution_trace = ...
(note extra *)

Mike.

My idea of all of this is that a TM could do this same
sort of thing. The outer TM knows its own tape and
allocates a portion of this tape to slave instance of
itself. Each instance of these TM's thinks that a single
execution_trace belongs to itself alone.

A TM Could not do the same sort of thing,

Mike has already agreed that a TM that is a UTM
can examine every aspect of the internals of its
slave UTMs.

None of the details of HOW HHH determines that
its finite string input specifies non terminating
behavior is relevant UNTIL AFTER IT IS UNDERSTOOD THAT
ITS FINITE STRING INPUT SPECIFIES NON TERMINATING BEHAVIOR.

Understanding is not relevant. A proof would be if there were one.
As long as there is none it is sufficient to say that the claim is
unproven.

--
Mikko

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

Op 01.mrt.2025 om 01:41 schreef olcott:

On 2/28/2025 2:36 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 22:42 schreef olcott:

It is flat out dishonest to change the subject away
from DD emulated by HHH.

It is flat out incorrect to suggest that this DD is a different one.
There is only one finite string, describing only one behaviour.

It is a verified fact that the directly executed DD has a
different execution trace than DD emulated by HHH.

People try to get away with saying this is wrong are dumbfounded
when I challenge them to provide the correct execution trace
of DD emulated by HHH.

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

It is perfectly fine to say that you just don't understand
that. What is terribly wrong is for you to know that you
don't understand that and claim that I am incorrect.

When we hypothesize that the code at machine address
0000213c is an x86 emulator then we know that DD
remains stuck in recursive emulation and cannot possibly
reach its own "ret" instruction and terminate normally.

If Olcott really has only a few weeks left to complete his proof, he
should continue with the next step. He is repeating this for several
months and there is no progress.
Let's agree that Olcott's HHH indeed fails to reach the 'ret'
instruction of the finite string that, when given for direct execution
has no problem to reach the 'ret' instruction.
What is the next step? What does this failure of HHH imply?
As far as I can see, it is only more evidence for the halting theorem.

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

Am Fri, 28 Feb 2025 18:41:08 -0600 schrieb olcott:

On 2/28/2025 2:36 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 22:42 schreef olcott:

It is flat out incorrect to suggest that this DD is a different one.
There is only one finite string, describing only one behaviour.

It is a verified fact that the directly executed DD has a different
execution trace than DD emulated by HHH.

Yes, HHH emulates DD verifiably incorrect.

People try to get away with saying this is wrong are dumbfounded when I challenge them to provide the correct execution trace of DD emulated by
HHH.

It is the trace of HHH1 emulating DD (where DD calls HHH).

When we hypothesize that the code at machine address 0000213c is an x86 emulator then we know that DD remains stuck in recursive emulation and
cannot possibly reach its own "ret" instruction and terminate normally.

HHH is not an emulator though.

When we add the additional complexity that HHH also aborts this sequence
at some point then every level of recursive emulation stops. This does
not enable any DD to ever reach its "ret" instruction.

Yes it does, because HHH returns to DD.

If this is beyond your technical competence THAT DOES NOT MAKE ME WRONG

That this is beyond your technical competence does not make you right.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 2/28/25 7:41 PM, olcott wrote:

On 2/28/2025 2:36 AM, Fred. Zwarts wrote:

Op 27.feb.2025 om 22:42 schreef olcott:

It is flat out dishonest to change the subject away
from DD emulated by HHH.

It is flat out incorrect to suggest that this DD is a different one.
There is only one finite string, describing only one behaviour.

It is a verified fact that the directly executed DD has a
different execution trace than DD emulated by HHH.

Then VERIFY IT,

What is the first instruction in the execution trace of the directly
executed DD differs from that in the emulated by HHH.

This has been asked for before and never actually answered, proving that
you claim is just a blantant lie. At best you try to argue that HHH is
allowed to incorrect emulate instuctions and the difference is that HHH
get to assume incorrect behavior for HHH.

Sorry, your "logic" is just built on lies.

People try to get away with saying this is wrong are dumbfounded
when I challenge them to provide the correct execution trace
of DD emulated by HHH.

Execpt you don't, because you edit out parts you don't loke, and add in
things that don't happen,

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

It is perfectly fine to say that you just don't understand
that. What is terribly wrong is for you to know that you
don't understand that and claim that I am incorrect.

So, why don't you do that?

Your error has been pointed out, and you just ignore it, because you
don't believe in facts. That just proves that you are just a stupid path

When we hypothesize that the code at machine address
0000213c is an x86 emulator then we know that DD
remains stuck in recursive emulation and cannot possibly
reach its own "ret" instruction and terminate normally.

And thus you prove that you arguement is built on the belief in a Truth
Fairy that can make a statement true that isn't. At 0000213c isn't a
correct emulator, but just a partial one that will abort its emulation
and return. We know that as your arguement has it do that. Thus, your
argument is based on LIES.

When we add the additional complexity that HHH also
aborts this sequence at some point then every level
of recursive emulation stops. This does not enable
any DD to ever reach its "ret" instruction.

Which makes it NOT a correct emulation, and breaks the conclusion you
made about DD.

If this is beyond your technical competence
THAT DOES NOT MAKE ME WRONG

That you dont understand how programs works, does.

Your logic is just built on lies.

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

On 3/1/25 5:02 PM, olcott wrote:

On 3/1/2025 2:10 AM, Mikko wrote:

On 2025-03-01 01:16:41 +0000, olcott said:

On 2/28/2025 3:16 AM, Mikko wrote:

On 2025-02-27 15:29:31 +0000, olcott said:

No, it is correct to report that HHH is unable to correctly
simulate this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

Do you mean that having no end enables the simulation to the end?

see my new post
DD emulated by HHH cannot possibly terminate normally --- x86 code

In that post:

DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

When we hypothesize that the code at machine address
0000213c is an x86 emulator then we know that DD
remains stuck in recursive emulation and cannot possibly
reach its own "ret" instruction and terminate normally.

When we add the additional complexity that HHH also
aborts this sequence at some point then every level
of recursive emulation immediately stops. This does
not enable any DD to ever reach its "ret" instruction.

The question remains unanswered. If the author cannot tell what he
means we may assume that he didn't mean anything.

Your question applied to my ambiguous verbiage.
I cancel that ambiguous verbiage and say that
DD emulated by HHH cannot possibly reach its
own "ret" instruction.

Which is just a strawman, proving that you are just a fraud.

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

On 2025-03-01 22:02:44 +0000, olcott said:

On 3/1/2025 2:10 AM, Mikko wrote:

On 2025-03-01 01:16:41 +0000, olcott said:

On 2/28/2025 3:16 AM, Mikko wrote:

On 2025-02-27 15:29:31 +0000, olcott said:

No, it is correct to report that HHH is unable to correctly simulate >>>>>> this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

Do you mean that having no end enables the simulation to the end?

see my new post
DD emulated by HHH cannot possibly terminate normally --- x86 code

In that post:

DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

When we hypothesize that the code at machine address
0000213c is an x86 emulator then we know that DD
remains stuck in recursive emulation and cannot possibly
reach its own "ret" instruction and terminate normally.

When we add the additional complexity that HHH also
aborts this sequence at some point then every level
of recursive emulation immediately stops. This does
not enable any DD to ever reach its "ret" instruction.

The question remains unanswered. If the author cannot tell what he
means we may assume that he didn't mean anything.

Your question applied to my ambiguous verbiage.
I cancel that ambiguous verbiage and say that
DD emulated by HHH cannot possibly reach its
own "ret" instruction.

You should also say that the words you intend to retract are "In other
words you are totally clueless that infinite recursion HAS NO END".
Until you do so my question is valid.

--
Mikko

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

On 3/1/25 11:31 PM, olcott wrote:

On 3/1/2025 7:14 PM, Richard Damon wrote:

On 3/1/25 5:02 PM, olcott wrote:

On 3/1/2025 2:10 AM, Mikko wrote:

On 2025-03-01 01:16:41 +0000, olcott said:

On 2/28/2025 3:16 AM, Mikko wrote:

On 2025-02-27 15:29:31 +0000, olcott said:

No, it is correct to report that HHH is unable to correctly
simulate this halting program up to its end.

In other words you are totally clueless that infinite
recursion HAS NO END.

Do you mean that having no end enables the simulation to the end?

see my new post
DD emulated by HHH cannot possibly terminate normally --- x86 code

In that post:

DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

When we hypothesize that the code at machine address
0000213c is an x86 emulator then we know that DD
remains stuck in recursive emulation and cannot possibly
reach its own "ret" instruction and terminate normally.

When we add the additional complexity that HHH also
aborts this sequence at some point then every level
of recursive emulation immediately stops. This does
not enable any DD to ever reach its "ret" instruction.

The question remains unanswered. If the author cannot tell what he
means we may assume that he didn't mean anything.

Your question applied to my ambiguous verbiage.
I cancel that ambiguous verbiage and say that
DD emulated by HHH cannot possibly reach its
own "ret" instruction.

Which is just a strawman, proving that you are just a fraud.

I don't have time left to talk in circles

DD emulated by HHH cannot possibly reach its
own "ret" instruction.

Anything else STFU about it.

In other words, you admit to using a strawman, as the question to a halt decider isn't can *IT* emulate the input to a final state, but does the
input represent a program that will halt or not, or would an actually
correct emulation of the input reach a final state,

Your use of this strawman just proves you are ignorant of what you talk
about, and that you just don't care about the truth, becuase you are
nothing but a pathological liar trying to pass a fraud, which is going
to be your eternal reputation.

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