On 2025-11-23, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
On 2025-11-22, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
On 2025-11-22, olcott <polcott333@gmail.com> wrote:
is exactly the same as HHH except that DD does not
call HHH1(DD) in recursive simulation.
I already pointed out the massive problem with this.
If HHH1 is identical to HHH, it means that HHH1 and HHH
are only different names for exactly the same function.
In the mathematical abstraction that simply pretends
the behavioral details don't exist the math itself is
also a damned liar.
The fact that two different names are used to refer to exactly the same
function does not constitute a "behavior detail" of that function.
That you are trying to get away with ignoring these
details from the stipulated perspective of the execution
trace in C according to the semantics of C makes you
a damned liar even when referring to the mathematical
abstraction.
If you want your C functions to correspond to recursive
functions in computation theory, you have to code them
according to certain rules.
One of those is that you may not conclude that if f1 != f2 (pointer
comparison) then they are different functions.
HHH1 is at line 589 - 665
HHH is at line 1081 - 1156
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When DD calls HHH through of C interpreter
it does not call HHH1 because HHH1 has a
different name and is at a different location.
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software, HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually interchangeable operations.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
The problem is that you have logic which concludes that HHH1 != HHH (low >>> level pointer comparison), they are different functions.
Except when their input calls themself.
That makes no difference.
[000022e1] 33c0ÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[000022e3] 5dÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[000022e4] c3ÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Except when their input calls themself.
In this case they must simulate themselves
simulating their input, not just simulate
their input.
On 11/24/2025 11:55 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software, >>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
The problem is that you have logic which concludes that HHH1 != HHH (low >>>> level pointer comparison), they are different functions.
Except when their input calls themself.
That makes no difference.
typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
HHH1(DD);
}
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 12:12 PM, Mike Terry wrote:
Right - in terms of their results when called.
So stupidly incorrect that I can't believe
that Mike believes this.
Maybe the stupid one is you, and other people who are agree with each
other are right?
Naaaah, that could not possibly be ...
You must have deep connections in the US Department of Defense;
otherwise, how the hell did you get your hands on such a
high weapons-grade Dunning Kruger ...
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 11:55 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>> different adddresses, not recognized as identical by the compiler and >>>>> not folded into one copy, in a correct implementation of your software, >>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
The problem is that you have logic which concludes that HHH1 != HHH (low >>>>> level pointer comparison), they are different functions.
Except when their input calls themself.
That makes no difference.
typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
Please, don't post this repeated crap any more.
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
ÿÿÿ HHH(DD);
ÿÿÿ HHH1(DD);
ÿÿÿ return 0;
}
_main()
[000022c4] 55ÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000022c5] 8becÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000022c7] 6834220000ÿÿÿÿ push 00002234 ; push DD
[000022cc] e833f3ffffÿÿÿÿ call 00001604 ; call HHH
[000022d1] 83c404ÿÿÿÿÿÿÿÿ add esp,+04
[000022d4] 6834220000ÿÿÿÿ push 00002234 ; push DD
[000022d9] e856f2ffffÿÿÿÿ call 00001534 ; call HHH1
[000022de] 83c404ÿÿÿÿÿÿÿÿ add esp,+04
[000022e1] 33c0ÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[000022e3] 5dÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[000022e4] c3ÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and there's no reason that an emulator emulating
the TM is required to identify such copies as being copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it
has multiple copies of the same algorithm with different state
labels...ÿ Your point that the /results/ of those copied algorithms must
be the same is spot on though.
The problem is that you have logic which concludes that HHH1 != HHH (low
level pointer comparison), they are different functions.
If we were talking about H and H1, this would be a reasonable
explanation.ÿ Your approach of changing pointer comparison to consider
H/H1 the same would fix the problem.ÿ Another way of looking at things
would be that H and H1 use different global constants in their
algorithms (viz H uses H [address of function H] and H1 uses H1 [address
of function H1].ÿ No surprise they give different results!ÿ If instead
say H used literal 17, and H1 used literal 19, this explanation would be obvious, but H/H1/17/19 are all examples of "global constants".ÿ Looked
at this way, we can fix the problem by changing H1 to make it "a proper
copy of H", that would require changing the H1 in H1's body to H, and
then behaviour of H/H1 would be the same.ÿÿ [Which fix approach is
better depends on what you consider the essential problem to be.]
For HHH/HHH1 the issue is different - they are clearly different
algorithms since they give different results,
but it's not pointer
comparison that is the problem - it's the use of mutable global data:
HHH and HHH1 each use /their own/ global variable [viz their global
trace tables] within their algorithms.ÿ It so happens that in this case,
the global data is a static variable, and so it /appears/ at first
glance as though they are the same - they have the same name in both HHH/HHH1, but behind the scenes they are scoped to HHH/HHH1
respectively, and are different data items.ÿ I imagine the compiler qualifies the storage label with the function name somehow behind the scenes, but don't know the details.ÿ Meanwhile PO gets to claim "they
are the same -
just compare the function bodies!".ÿ [The effect of all
this, is that HHH only sees trace entries "delivered" from nested HHH's,
and HHH1 only sees trace entries "delivered" from nested HHH1's (of
which there are none!) - no surprise that they produce different results.]
One way to fix this [akin to my H/H1 fix], would be to make HHH1
processing match HHH, e.g. change both HHH/HHH1 to use a common global- scope variable rather than a static-cope ones.ÿ This leaves the
underlying problems of invalid global data use, but at least HHH/HHH1
are now equivalent.ÿ The proper way of fixing the problem would be to
get rid of the improper use of global data in both HHH/HHH1.ÿ With
either of these fixes HHH and HHH1 would produce the same result [neverhalts].
Changing the function pointer address comparison in HHH/HHH1 would not
fix the problem.ÿ [I suppose I should confirm this at some point, as
I've claimed it several times!]
Coming back to my first remark about /results/ of copied algorithms
being the same, with either of my proposed fixes this becomes true - HHH/HHH1 produce the same result for DD.ÿ They would also produce the
same result for DD_HHH1.ÿ That's not to say that a decider /emulating/
HHH or HHH1 must identify HHH/HHH1 within the emulation as the same -
sure, it's /allowed/ to try and do that, but not required to; the
decider can do as it pleases.ÿ Just as a TM decider could spot a loop
while emulating its input TM-desc, where the emulation is stuck on state q_13, without caring whether q13 is part of some algorithm with multiple copies throughout the TM-description, making q_13 "equivalent" to say
q_39 and to q_72.
Mike.
As long as you keep lying I will keep repeating it.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>> different adddresses, not recognized as identical by the compiler and >>>>> not folded into one copy, in a correct implementation of your software, >>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to identify such copies as being
copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
multiple copies of the same algorithm with different state labels... Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X and CALL Y occur in
the trace buffer, without any intervening conditionals in between but X
!= Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
The fact that you keep reiterating about how things /are/ in your
code, when I'm making effort to clarify that I'm talking about how
they are /supposed/ to be, shows me you are not comprehending
what you are reading.
Anyone that even knows what
ordinary recursion is should get this
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
That, I'm saying, is not a valid concept.
The actual reason is that you are failing to identify HHH
and HHH1 as equivalent by using address comparisons.
The same function can be known under multiple addresses, just
like under different names. That's an implementation detail you
have to abstract away if you want to correctly model pure, recursive functions which behave like their mathematical counterparts in key ways.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:30 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 12:12 PM, Mike Terry wrote:
Right - in terms of their results when called.
So stupidly incorrect that I can't believe
that Mike believes this.
Maybe the stupid one is you, and other people who are agree with each
other are right?
Naaaah, that could not possibly be ...
You must have deep connections in the US Department of Defense;
otherwise, how the hell did you get your hands on such a
high weapons-grade Dunning Kruger ...
That you only have mere empty rhetoric that
has no basis seems to prove that you know
that you are not telling the truth.
Are you saying you are disappointed that your relevant and
substantial bit of rhetoric above, namely;
"So stupidly incorrect that I can't believe mike believes this"
did not elicit an equally deep followup?
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
As long as you keep lying I will keep repeating it.
To lie is to knowing post something that is false.
But if you do that about an objectively verifiable fact that has nothing
to do with yourself, but some scientific matter, nobody in their right
mind will see you as a liar.
Rather than see you as a liar, they will just assume you are ignorant
and incompetent.
What makes you think I, or Mike, or anyone here would write something I
know to be false, which would be interpreted as ignorant, rather than dishonest?
Maybe you don't understand that nobody would do that, since
you have no problem being casually wrong yourself.
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
For HHH/HHH1 the issue is different - they are clearly different algorithms since they give
different results, but it's not pointer comparison that is the problem - it's the use of mutable
global data: HHH and HHH1 each use /their own/ global variable [viz their global trace tables]
within their algorithms.
Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure functions since they react to this mutating state.
Multiplie instances of HHH share an execution trace buffer, allocated
by the first call to HHH.
Multiple instances of HHH1 also share an execution trace buffer distinct
from that one allocated by the first call to HHH1.
Simulations conducted by any level of HHH only feed HHH's buffer,
and simulations conducted by any level of HHH1 only feed HHH1's buffer.
That is all gapingly incorrect; yet if these aspects were fixed, there
would still be a problem if we evaluate HHH1 != HHH as dincating that
they are different function.
It so happens that in this case, the global data is a static variable, and >> so it /appears/ at first glance as though they are the same - they have the same name in both
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
One way to fix this [akin to my H/H1 fix], would be to make HHH1 processing match HHH, e.g. change
both HHH/HHH1 to use a common global-scope variable rather than a static-cope ones. This leaves the
underlying problems of invalid global data use, but at least HHH/HHH1 are now equivalent. The
proper way of fixing the problem would be to get rid of the improper use of global data in both
HHH/HHH1. With either of these fixes HHH and HHH1 would produce the same result [neverhalts].
Olcott thinks that by moving the static data into the code space of the function, and using asssembly instructions and whatnot, such that the C keyword "static" does not appear, means that he has fixed the issue of relying on static data.
On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then >>>>>>>> in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
ÿÿÿÿÿ HHH(DD);
ÿÿÿÿÿ HHH1(DD);
ÿÿÿÿÿ return 0;
}
_main()
[000022c4] 55ÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000022c5] 8becÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000022c7] 6834220000ÿÿÿÿ push 00002234 ; push DD
[000022cc] e833f3ffffÿÿÿÿ call 00001604 ; call HHH
[000022d1] 83c404ÿÿÿÿÿÿÿÿ add esp,+04
[000022d4] 6834220000ÿÿÿÿ push 00002234 ; push DD
[000022d9] e856f2ffffÿÿÿÿ call 00001534 ; call HHH1
[000022de] 83c404ÿÿÿÿÿÿÿÿ add esp,+04
[000022e1] 33c0ÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[000022e3] 5dÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[000022e4] c3ÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>>> different adddresses, not recognized as identical by the compiler and >>>>>> not folded into one copy, in a correct implementation of your
software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct
copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to
identify such copies as being
copies - an emulator just has to mimic what the TM would do and the >>>>> TM doesn't know that it has
multiple copies of the same algorithm with different state
labels...ÿ Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL Xÿ and CALL Y occur in >>>> the trace buffer, without any intervening conditionals in between but X >>>> != Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
That wold be a lie.
It is like you are trying to get away with saying
that identical twins are one and the same person.
The identity of indiscernibles is an ontological principle
that states that there cannot be separate objects or entities
that have all their properties in common. https://en.wikipedia.org/wiki/Identity_of_indiscernibles
Even if identical twins had every single atom that
was identical they these atoms differ in their x,y,z
coordinates relative to the center of the Earth.
The fact that you keep reiterating about how things /are/ in your
code, when I'm making effort to clarify that I'm talking about how
they are /supposed/ to be, shows me you are not comprehending
what you are reading.
Anyone that even knows what
ordinary recursion is should get this
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
You keep thinking in mathematical terms that abstract
away (thus simply ignore) key differences.
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
You really can't be stupid enough to not see the
different execution trace.
That, I'm saying, is not a valid concept.
The actual reason is that you are failing to identify HHH
and HHH1 as equivalent by using address comparisons.
That essentially prove that identical twins are not
one and the same person.
the comp.lang.c and comp.lang.c++ groups will
continue to be presented with your non-sense
until they call you out on it.
The same function can be known under multiple addresses, just
like under different names. That's an implementation detail you
have to abstract away if you want to correctly model pure, recursive
functions which behave like their mathematical counterparts in key ways.
On 24/11/2025 19:27, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in >>>>>> fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
ÿÿÿÿ HHH(DD);
ÿÿÿÿ HHH1(DD);
ÿÿÿÿ return 0;
}
_main()
[000022c4] 55ÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000022c5] 8becÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000022c7] 6834220000ÿÿÿÿ push 00002234 ; push DD
[000022cc] e833f3ffffÿÿÿÿ call 00001604 ; call HHH
[000022d1] 83c404ÿÿÿÿÿÿÿÿ add esp,+04
[000022d4] 6834220000ÿÿÿÿ push 00002234 ; push DD
[000022d9] e856f2ffffÿÿÿÿ call 00001534 ; call HHH1
[000022de] 83c404ÿÿÿÿÿÿÿÿ add esp,+04
[000022e1] 33c0ÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[000022e3] 5dÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[000022e4] c3ÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software, >>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies
of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to
identify such copies as being
copies - an emulator just has to mimic what the TM would do and the
TM doesn't know that it has
multiple copies of the same algorithm with different state labels...
Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
Yep.ÿ There are two such comparisons:
-ÿÿ the addresses of the CALL instructions are compared
-ÿÿ the targets of the CALL instructions are compared
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL Xÿ and CALL Y occur in
the trace buffer, without any intervening conditionals in between but X
!= Y, then it is not concluded that it is a loop.
Yep.ÿ That's not actually a problem.ÿ Possibly a genuine loop might be overlooked, but the point is that if the addresses /do/ match that could
be a loop (subject to the other conditions matching).
Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses against /their own/ addresses?ÿ They don't do that.ÿ [H/H1 do that.]
All compared addresses (whether by HHH/HHH1) are trace addresses from
the DD() simulation, which is the same whether HHH or HHH1 is doing the emulation [up to the point HHH aborts and HHH1 carries on].ÿ So if you
were right, the behaviour would in any case be the same for HHH/HHH1 and couldn't account for differing HHH/HHH1 results.
That is why HHH1 and HHH show different results, even though they are
identical.
That comparison is the root cause why it matters that DD calls HHH
and not HHH1.
Not so, but I'll perform the test...
A complication:ÿ there are TWO occasions where trace address comparisons occur, as I listed above: the TARGETS of the two call instructions are compared, and the ADDRESSES of the call instructions are compared.
You want to equate "equivalent" addresses.ÿ For the TARGET addresses
this is easy-peasy as I will just check if they are both HHH/HHH1.ÿ For
the CALL instruction addresses, these will not be HHH/HHH1, but
logically the CALL addresses in different (equivalent) routines should
be considered equivalent???ÿ What would you like done here?ÿ [Perhaps if addresses are at the same offset within HHH/HHH1 they could be
considered equivalent.ÿ That's a slight pain, but doable.]
You know what - I've just realised HHH/HHH1 are only called from DD, and there's only one DD so this issue doesn't matter in our scenario!ÿ The
CALL instruction addresses will always be the same when HHH/HHH1 are
called.ÿ I'll just ignore the issue for now.ÿ (I'll trace the
comparisons and results so we can check this in the logs.)
Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
the root cause of the difference.
Well that's PO for you!ÿ It's simply that HHH/HHH1 are different
algorithms (each working off their own static trace table).
If addressees are compared with a CompareFunctions(X, Y) function
whch ensures that HHH and HHH1 are considered equal, then that
difference will disappear.
But there will still be the problem I explained with the HHH/HHH1
having /their own/ static trace tables...
Mike.
On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>>> different adddresses, not recognized as identical by the compiler and >>>>>> not folded into one copy, in a correct implementation of your software, >>>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to identify such copies as being
copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
multiple copies of the same algorithm with different state labels... Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X and CALL Y occur in >>>> the trace buffer, without any intervening conditionals in between but X >>>> != Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
That wold be a lie.
It is like you are trying to get away with saying
that identical twins are one and the same person.
The identity of indiscernibles is an ontological principle
that states that there cannot be separate objects or entities
that have all their properties in common.
https://en.wikipedia.org/wiki/Identity_of_indiscernibles
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
You keep thinking in mathematical terms that abstract
away (thus simply ignore) key differences.
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
You really can't be stupid enough to not see the
different execution trace.
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
That is the key difference
That is the key difference
On 24/11/2025 23:33, Mike Terry wrote:
On 24/11/2025 19:27, Kaz Kylheku wrote:<..snip..>
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
Yep.ÿ There are two such comparisons:
-ÿÿ the addresses of the CALL instructions are compared
-ÿÿ the targets of the CALL instructions are compared
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL Xÿ and CALL Y occur in
the trace buffer, without any intervening conditionals in between but X
!= Y, then it is not concluded that it is a loop.
Yep.ÿ That's not actually a problem.ÿ Possibly a genuine loop might be
overlooked, but the point is that if the addresses /do/ match that
could be a loop (subject to the other conditions matching).
Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses
against /their own/ addresses?ÿ They don't do that.ÿ [H/H1 do that.]
All compared addresses (whether by HHH/HHH1) are trace addresses from
the DD() simulation, which is the same whether HHH or HHH1 is doing
the emulation [up to the point HHH aborts and HHH1 carries on].ÿ So if
you were right, the behaviour would in any case be the same for HHH/
HHH1 and couldn't account for differing HHH/HHH1 results.
That is why HHH1 and HHH show different results, even though they are
identical.
That comparison is the root cause why it matters that DD calls HHH
and not HHH1.
Not so, but I'll perform the test...
*First test* :ÿ HHH(DD) with 1st version of CompareFunctions()
u32 CompareFunctions (u32 addr1, u32 addr2)
{
ÿ u32 bRet = (addr1 == addr2);
ÿ OutputString ("CompareFunctions:");
ÿ Output ("ÿ Addr1 = ", addr1);
ÿ Output ("ÿ Addr2 = ", addr2);
ÿ Output ("ÿ Returning Addr2 = ", bRet);
ÿ return bRet;
}
This is functionally the same as the current HHH/HHH1, because I have
not tried to match HHH/HHH1 functions.ÿ Effectively it is just adding
log output for the comparisons, so we can see /what/ is currently being compared.
Log output:
_DD()
[000025e9] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000025ea] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000025ec] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[000025ed] 68e9250000ÿÿÿÿÿÿ push 000025e9
[000025f2] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9
[000025f7] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[000025fa] 8945fcÿÿÿÿÿÿÿÿÿÿ mov [ebp-04],eax
[000025fd] 837dfc00ÿÿÿÿÿÿÿÿ cmp dword [ebp-04],+00
[00002601] 7402ÿÿÿÿÿÿÿÿÿÿÿÿ jz 00002605
[00002603] ebfeÿÿÿÿÿÿÿÿÿÿÿÿ jmp 00002603
[00002605] 8be5ÿÿÿÿÿÿÿÿÿÿÿÿ mov esp,ebp
[00002607] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[00002608] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0032) [00002608]
_main()
[00002609] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[0000260a] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[0000260c] 68e9250000ÿÿÿÿÿÿ push 000025e9
[00002611] e8c3f7ffffÿÿÿÿÿÿ call 00001dd9
[00002616] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[00002619] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
[0000261a] 68e7070000ÿÿÿÿÿÿ push 000007e7
[0000261f] e8e5e1ffffÿÿÿÿÿÿ call 00000809
[00002624] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
[00002627] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[00002629] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[0000262a] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0034) [0000262a]
ÿSÿ machineÿÿ stackÿÿÿÿ stackÿÿÿÿ machineÿÿÿÿÿÿÿÿÿ assembly
ÿIÿ addressÿÿ addressÿÿ dataÿÿÿÿÿ codeÿÿÿÿÿÿÿÿÿÿÿÿ language
ÿMÿ (before)ÿ (after)ÿÿ (after)
ÿ=ÿ ========ÿ ========ÿ ========ÿ ===============ÿ =============
ÿÿ [00002609][0010400b][00000000] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
ÿÿ [0000260a][0010400b][00000000] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
ÿÿ [0000260c][00104007][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
ÿÿ [00002611][00104003][00002616] e8c3f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
ÿÿ New slave_stack at:1040af
Begin Local Halt Decider Simulationÿÿ Execution Trace Stored at:1140b7 [1][000025e9][001140a7][001140ab] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp [1][000025ea][001140a7][001140ab] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp [1][000025ec][001140a3][001040af] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx [1][000025ed][0011409f][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9 [1][000025f2][0011409b][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH [1]New slave_stack at:14ead7
[2][000025e9][0015eacf][0015ead3] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp [2][000025ea][0015eacf][0015ead3] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp [2][000025ec][0015eacb][0014ead7] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx [2][000025ed][0015eac7][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9 [2][000025f2][0015eac3][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
ÿÿ CompareFunctions:
ÿÿÿÿ Addr1 = 25f2
ÿÿÿÿ Addr2 = 25f2
ÿÿÿÿ Returning Addr2 = 1
ÿÿ CompareFunctions:
ÿÿÿÿ Addr1 = 1dd9
ÿÿÿÿ Addr2 = 1dd9
ÿÿÿÿ Returning Addr2 = 1
ÿÿ Local Halt Decider: Infinite Recursion Detected Simulation Stopped
ÿÿ [00002616][0010400b][00000000] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
ÿÿ [00002619][00104007][00000000] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
ÿÿ [0000261a][00104003][000007e7] 68e7070000ÿÿÿÿÿÿ push 000007e7
ÿÿ [0000261f][00104003][000007e7] e8e5e1ffffÿÿÿÿÿÿ call 00000809ÿÿ ;
VMI:ÿ _Output
ÿÿ HHH(DD)ÿÿÿÿ ---> 0
ÿÿ [00002624][0010400b][00000000] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
ÿÿ [00002627][0010400b][00000000] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
ÿÿ [00002629][0010400f][00000018] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
ÿÿ [0000262a][00104013][00000000] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Number of Instructions Executed(12070) == 180 Pages
Summary:
HHH[0] (outer HHH called from main) detects "Infinite Recursion" and
returns 0 [neverhalts].
*IMPORTANT NOTE* : CompareFunctions() is only called twice, both calls
from the same invocation of Needs_To_Be_Aborted_Trace_HH().ÿ The first
is comparing the CALL instruction addresses which are equal [00002fee is
in function DD].ÿ The second call is comparing the target addresses
being called. ÿ[00001d55 is HHH].ÿ *Both comparisons are comparing
IDENTICAL addresses*
========================
*Second test* :ÿ *HHH1(DD)* with 1st version of CompareFunctions() [as
for 1st test]
Effectively it's the current HHH1(DD) with comparison logging.ÿÿ [If HHH address is never being compared with HHH1 address in this test, there is
no point going further!]
Log output:
_DD()
[000025e9] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000025ea] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000025ec] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[000025ed] 68e9250000ÿÿÿÿÿÿ push 000025e9
[000025f2] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9
[000025f7] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[000025fa] 8945fcÿÿÿÿÿÿÿÿÿÿ mov [ebp-04],eax
[000025fd] 837dfc00ÿÿÿÿÿÿÿÿ cmp dword [ebp-04],+00
[00002601] 7402ÿÿÿÿÿÿÿÿÿÿÿÿ jz 00002605
[00002603] ebfeÿÿÿÿÿÿÿÿÿÿÿÿ jmp 00002603
[00002605] 8be5ÿÿÿÿÿÿÿÿÿÿÿÿ mov esp,ebp
[00002607] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[00002608] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0032) [00002608]
_main()
[00002609] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[0000260a] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[0000260c] 68e9250000ÿÿÿÿÿÿ push 000025e9
[00002611] e8b3efffffÿÿÿÿÿÿ call 000015c9
[00002616] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[00002619] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
[0000261a] 68e7070000ÿÿÿÿÿÿ push 000007e7
[0000261f] e8e5e1ffffÿÿÿÿÿÿ call 00000809
[00002624] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
[00002627] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[00002629] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[0000262a] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0034) [0000262a]
ÿSÿ machineÿÿ stackÿÿÿÿ stackÿÿÿÿ machineÿÿÿÿÿÿÿÿÿ assembly
ÿIÿ addressÿÿ addressÿÿ dataÿÿÿÿÿ codeÿÿÿÿÿÿÿÿÿÿÿÿ language
ÿMÿ (before)ÿ (after)ÿÿ (after)
ÿ=ÿ ========ÿ ========ÿ ========ÿ ===============ÿ =============
ÿÿ [00002609][0010400b][00000000] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
ÿÿ [0000260a][0010400b][00000000] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
ÿÿ [0000260c][00104007][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
ÿÿ [00002611][00104003][00002616] e8b3efffffÿÿÿÿÿÿ call 000015c9ÿÿ ; _HHH1
ÿÿ New slave_stack at:1040af
Begin Local Halt Decider Simulationÿÿ Execution Trace Stored at:1140b7 [1][000025e9][001140a7][001140ab] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp [1][000025ea][001140a7][001140ab] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp [1][000025ec][001140a3][001040af] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx [1][000025ed][0011409f][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9 [1][000025f2][0011409b][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH [1]New slave_stack at:14ead7
[1]
Begin Local Halt Decider Simulationÿÿ Execution Trace Stored at:15eadf [2][000025e9][0015eacf][0015ead3] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp [2][000025ea][0015eacf][0015ead3] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp [2][000025ec][0015eacb][0014ead7] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx [2][000025ed][0015eac7][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9 [2][000025f2][0015eac3][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH [2]New slave_stack at:1994ff
[3][000025e9][001a94f7][001a94fb] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp [3][000025ea][001a94f7][001a94fb] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp [3][000025ec][001a94f3][001994ff] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx [3][000025ed][001a94ef][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9 [3][000025f2][001a94eb][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH [1]CompareFunctions:
[1]ÿ Addr1 = 25f2
[1]ÿ Addr2 = 25f2
[1]ÿ Returning Addr2 = 1
[1]CompareFunctions:
[1]ÿ Addr1 = 1dd9
[1]ÿ Addr2 = 1dd9
[1]ÿ Returning Addr2 = 1
[1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[1][000025f7][001140a3][001040af] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04 [1][000025fa][001140a3][00000000] 8945fcÿÿÿÿÿÿÿÿÿÿ mov [ebp-04],eax [1][000025fd][001140a3][00000000] 837dfc00ÿÿÿÿÿÿÿÿ cmp dword [ebp-04],+00 [1][00002601][001140a3][00000000] 7402ÿÿÿÿÿÿÿÿÿÿÿÿ jz 00002605 [1][00002605][001140a7][001140ab] 8be5ÿÿÿÿÿÿÿÿÿÿÿÿ mov esp,ebp [1][00002607][001140ab][0000167e] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp [1][00002608][001140af][0003a980] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
ÿÿ [00002616][0010400b][00000000] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
ÿÿ [00002619][00104007][00000001] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
ÿÿ [0000261a][00104003][000007e7] 68e7070000ÿÿÿÿÿÿ push 000007e7
ÿÿ [0000261f][00104003][000007e7] e8e5e1ffffÿÿÿÿÿÿ call 00000809ÿÿ ;
VMI:ÿ _Output
ÿÿ HHH1(DD)ÿÿÿ ---> 1
ÿÿ [00002624][0010400b][00000000] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
ÿÿ [00002627][0010400b][00000000] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
ÿÿ [00002629][0010400f][00000018] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
ÿÿ [0000262a][00104013][00000000] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Number of Instructions Executed(435547) == 6501 Pages
Summary:
HHH1[0] does not detect "Infinite Recursion".ÿ Instead, HHH1[1] detects
it [Observe simulation depth of "Infinite Recursion Detected" message.]
So HHH1[1] returns 0 to DD[1], and DD[1] halts.ÿ That is detected by
HHH[0], which decides DD halts.ÿ (This is the correct halting decision.)
*IMPORTANT NOTE* : CompareFunctions() is only called twice, just as for
Test 1, but in this case it is HHH[1] making the calls rather than
HHH[0].ÿÿÿ *Both comparisons are comparing IDENTICAL addresses*, the
same addresses compared in Test 1.
========================
*Third test* :
At this point I intended to change CompareFunctions() to include the HHH/HHH1 equivalency logic, but from Tests 1 and 2 it is clear that will make no difference, so I can't be bothered! :)ÿ For both the previous
tests the only comparisons performed are for exactly equal addresses, so
the result will not be changed by including function equivalency logic.
========================
*Forth and Fifth tests* :
These wouldÿ be running *MJT_HHH(MJT_DD)* and *MJT_HHH1(MJT_DD)* from
main.ÿ These are essentially versions of PO functions, but pure code examples (no misuse of shared global data).ÿ Again they would use the
same CompareFunctions() as previous tests, effectively just logging the address comparisons.
These two traces would match each other, both deciding that MJT_DD never halts.ÿ Essentially they will be like the HHH(DD) trace (Test 1), with MJT_HHH[0] and MJT_HHH1[0] each detecting "Infinite Recursion" and
deciding MJT_DD doesn't halt.ÿ Conclusion would be that the problem with PO's code is the misuse of global data.ÿ [...not the address comparison issue...]
But this post is surely already too long!ÿ [I'd be happy to post Tests
4&5 if anyone wants to see them.]
Mike.
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>>>> different adddresses, not recognized as identical by the compiler and >>>>>>> not folded into one copy, in a correct implementation of your software, >>>>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually >>>>>>> interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to identify such copies as being
copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
multiple copies of the same algorithm with different state labels... Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X and CALL Y occur in >>>>> the trace buffer, without any intervening conditionals in between but X >>>>> != Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
That wold be a lie.
I would not say anything that would be interpreted as wrong; nobody who
finds it wrong would think that I'm lying, only that I am misinformed
and ignorant. The last thing I want is to be misinformed and ignorant, misinforming others.
On 2025-11-24, olcott <NoOne@NoWhere.com> wrote:
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
That is the key difference
But that difference in the run-time of the system you have built is
propped up by bugs:
- relying on mutable static state, of which HHH and HHH1 have their own
instance.
- comparing function addresses as the basis of equality and inequality
- ...
That is the key difference
If you properly coded HHH1 and HHH as pure functions that are identical,
and compared equal even if they have different addresses, then there
would be no difference between HHH(DD) and HHH1(DD).
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
As long as you keep lying I will keep repeating it.
To lie is to knowing post something that is false.
But if you do that about an objectively verifiable fact
that has nothing to do with yourself, but some scientific
matter, nobody in their right mind will see you as a liar.
Rather than see you as a liar, they will just assume you
are ignorant and incompetent.
What makes you think I, or Mike, or anyone here would
write something I know to be false, which would be
interpreted as ignorant, rather than dishonest?
Maybe you don't understand that nobody would do that, since
you have no problem being casually wrong yourself.
The people on comp.lang.c or comp.lang.c++ can always speak
up.
typedef int (*ptr)(); int HHH(ptr P); int HHH1(ptr P);
int DD() { int Halt_Status = HHH(DD); if (Halt_Status) HERE:
goto HERE; return Halt_Status; }
int main() { HHH(DD); HHH1(DD); }
HHH simulates DD
[Follow-ups set]
On 24/11/2025 23:23, olcott wrote:
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
As long as you keep lying I will keep repeating it.
To lie is to knowing post something that is false.
But if you do that about an objectively verifiable fact
that has nothing to do with yourself, but some scientific
matter, nobody in their right mind will see you as a liar.
Rather than see you as a liar, they will just assume you
are ignorant and incompetent.
What makes you think I, or Mike, or anyone here would
write something I know to be false, which would be
interpreted as ignorant, rather than dishonest?
Maybe you don't understand that nobody would do that, since you have
no problem being casually wrong yourself.
The people on comp.lang.c or comp.lang.c++ can always speak
up.
They have done so, many times. They have told you many times that
you are wrong. You don't care, of course.
typedef int (*ptr)(); int HHH(ptr P); int HHH1(ptr P);
int DD() { int Halt_Status = HHH(DD); if (Halt_Status) HERE:
goto HERE; return Halt_Status; }
int main() { HHH(DD); HHH1(DD); }
HHH simulates DD
The rules of C offer no mechanism for HHH to be able to simulate any C function using nothing but a function pointer.
The closest you can get
is to dereference it, but you don't do that. Your 'simulation' doesn't simulate any part of DD past the call in its first line, and you can
only do that because of a platform-specific hack that breaks the rules
of C.
You have been told this many times, but you're not interested in truth
or competence., so (as Kaz rightly said) we all have to assume that you
are ignorant and incompetent.
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Followups set to comp.theory only, because nobody has anything to gain
from your cross-posting to language experts whose expert opinions you invariably ignore.
On 11/24/2025 8:15 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <NoOne@NoWhere.com> wrote:
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
That is the key difference
But that difference in the run-time of the system you have built is
propped up by bugs:
That is the kind of: "reckless disregard for the truth"
that loses libel cases.
- relying on mutable static state, of which HHH and HHH1 have their own
instance.
Is certainly not any kind of bug what-so-ever.
That statement is the kind of:
"reckless disregard for the truth"
that loses libel cases.
- comparing function addresses as the basis of equality and inequality
Is exactly how one can tell that the same function
has been called from the same address at the x86
level of semantics.
- ...
That is the key difference
If you properly coded HHH1 and HHH as pure functions that are identical,
and compared equal even if they have different addresses, then there
would be no difference between HHH(DD) and HHH1(DD).
I don't fully understand its analysis yet ChatGPT
seems to show how the static data can be implemented
using different segments of the Turing Machine tape. https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496
On 11/24/2025 8:10 PM, Mike Terry wrote:
On 24/11/2025 23:33, Mike Terry wrote:
On 24/11/2025 19:27, Kaz Kylheku wrote:<..snip..>
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
Yep.ÿ There are two such comparisons:
-ÿÿ the addresses of the CALL instructions are compared
-ÿÿ the targets of the CALL instructions are compared
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL Xÿ and CALL Y occur in >>>> the trace buffer, without any intervening conditionals in between but X >>>> != Y, then it is not concluded that it is a loop.
Yep.ÿ That's not actually a problem.ÿ Possibly a genuine loop might
be overlooked, but the point is that if the addresses /do/ match that
could be a loop (subject to the other conditions matching).
Hmm, maybe you're thinking that HHH/HHH1 are comparing trace
addresses against /their own/ addresses?ÿ They don't do that.ÿ [H/H1
do that.] All compared addresses (whether by HHH/HHH1) are trace
addresses from the DD() simulation, which is the same whether HHH or
HHH1 is doing the emulation [up to the point HHH aborts and HHH1
carries on].ÿ So if you were right, the behaviour would in any case
be the same for HHH/ HHH1 and couldn't account for differing HHH/HHH1
results.
That is why HHH1 and HHH show different results, even though they are
identical.
That comparison is the root cause why it matters that DD calls HHH
and not HHH1.
Not so, but I'll perform the test...
*First test* :ÿ HHH(DD) with 1st version of CompareFunctions()
u32 CompareFunctions (u32 addr1, u32 addr2)
{
ÿÿ u32 bRet = (addr1 == addr2);
ÿÿ OutputString ("CompareFunctions:");
ÿÿ Output ("ÿ Addr1 = ", addr1);
ÿÿ Output ("ÿ Addr2 = ", addr2);
ÿÿ Output ("ÿ Returning Addr2 = ", bRet);
ÿÿ return bRet;
}
This is functionally the same as the current HHH/HHH1, because I have
not tried to match HHH/HHH1 functions.ÿ Effectively it is just adding
log output for the comparisons, so we can see /what/ is currently
being compared.
Log output:
_DD()
[000025e9] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000025ea] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000025ec] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[000025ed] 68e9250000ÿÿÿÿÿÿ push 000025e9
[000025f2] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9
[000025f7] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[000025fa] 8945fcÿÿÿÿÿÿÿÿÿÿ mov [ebp-04],eax
[000025fd] 837dfc00ÿÿÿÿÿÿÿÿ cmp dword [ebp-04],+00
[00002601] 7402ÿÿÿÿÿÿÿÿÿÿÿÿ jz 00002605
[00002603] ebfeÿÿÿÿÿÿÿÿÿÿÿÿ jmp 00002603
[00002605] 8be5ÿÿÿÿÿÿÿÿÿÿÿÿ mov esp,ebp
[00002607] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[00002608] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0032) [00002608]
_main()
[00002609] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[0000260a] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[0000260c] 68e9250000ÿÿÿÿÿÿ push 000025e9
[00002611] e8c3f7ffffÿÿÿÿÿÿ call 00001dd9
[00002616] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[00002619] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
[0000261a] 68e7070000ÿÿÿÿÿÿ push 000007e7
[0000261f] e8e5e1ffffÿÿÿÿÿÿ call 00000809
[00002624] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
[00002627] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[00002629] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[0000262a] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0034) [0000262a]
ÿÿSÿ machineÿÿ stackÿÿÿÿ stackÿÿÿÿ machineÿÿÿÿÿÿÿÿÿ assembly
ÿÿIÿ addressÿÿ addressÿÿ dataÿÿÿÿÿ codeÿÿÿÿÿÿÿÿÿÿÿÿ language
ÿÿMÿ (before)ÿ (after)ÿÿ (after)
ÿÿ=ÿ ========ÿ ========ÿ ========ÿ ===============ÿ =============
ÿÿÿ [00002609][0010400b][00000000] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
ÿÿÿ [0000260a][0010400b][00000000] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
ÿÿÿ [0000260c][00104007][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
ÿÿÿ [00002611][00104003][00002616] e8c3f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ;
_HHH
ÿÿÿ New slave_stack at:1040af
Begin Local Halt Decider Simulationÿÿ Execution Trace Stored at:1140b7
[1][000025e9][001140a7][001140ab] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[1][000025ea][001140a7][001140ab] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[1][000025ec][001140a3][001040af] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[1][000025ed][0011409f][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
[1][000025f2][0011409b][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
[1]New slave_stack at:14ead7
[2][000025e9][0015eacf][0015ead3] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[2][000025ea][0015eacf][0015ead3] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[2][000025ec][0015eacb][0014ead7] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[2][000025ed][0015eac7][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
[2][000025f2][0015eac3][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
ÿÿÿ CompareFunctions:
ÿÿÿÿÿ Addr1 = 25f2
ÿÿÿÿÿ Addr2 = 25f2
ÿÿÿÿÿ Returning Addr2 = 1
ÿÿÿ CompareFunctions:
ÿÿÿÿÿ Addr1 = 1dd9
ÿÿÿÿÿ Addr2 = 1dd9
ÿÿÿÿÿ Returning Addr2 = 1
ÿÿÿ Local Halt Decider: Infinite Recursion Detected Simulation Stopped
ÿÿÿ [00002616][0010400b][00000000] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
ÿÿÿ [00002619][00104007][00000000] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
ÿÿÿ [0000261a][00104003][000007e7] 68e7070000ÿÿÿÿÿÿ push 000007e7
ÿÿÿ [0000261f][00104003][000007e7] e8e5e1ffffÿÿÿÿÿÿ call 00000809ÿÿ ;
VMI:ÿ _Output
ÿÿÿ HHH(DD)ÿÿÿÿ ---> 0
ÿÿÿ [00002624][0010400b][00000000] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
ÿÿÿ [00002627][0010400b][00000000] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
ÿÿÿ [00002629][0010400f][00000018] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
ÿÿÿ [0000262a][00104013][00000000] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Number of Instructions Executed(12070) == 180 Pages
Summary:
HHH[0] (outer HHH called from main) detects "Infinite Recursion" and
returns 0 [neverhalts].
*IMPORTANT NOTE* : CompareFunctions() is only called twice, both calls
from the same invocation of Needs_To_Be_Aborted_Trace_HH().ÿ The first
is comparing the CALL instruction addresses which are equal [00002fee
is in function DD].ÿ The second call is comparing the target addresses
being called. ÿ[00001d55 is HHH].ÿ *Both comparisons are comparing
IDENTICAL addresses*
========================
*Second test* :ÿ *HHH1(DD)* with 1st version of CompareFunctions() [as
for 1st test]
Effectively it's the current HHH1(DD) with comparison logging.ÿÿ [If
HHH address is never being compared with HHH1 address in this test,
there is no point going further!]
Log output:
_DD()
[000025e9] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[000025ea] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[000025ec] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[000025ed] 68e9250000ÿÿÿÿÿÿ push 000025e9
[000025f2] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9
[000025f7] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[000025fa] 8945fcÿÿÿÿÿÿÿÿÿÿ mov [ebp-04],eax
[000025fd] 837dfc00ÿÿÿÿÿÿÿÿ cmp dword [ebp-04],+00
[00002601] 7402ÿÿÿÿÿÿÿÿÿÿÿÿ jz 00002605
[00002603] ebfeÿÿÿÿÿÿÿÿÿÿÿÿ jmp 00002603
[00002605] 8be5ÿÿÿÿÿÿÿÿÿÿÿÿ mov esp,ebp
[00002607] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[00002608] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0032) [00002608]
_main()
[00002609] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[0000260a] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[0000260c] 68e9250000ÿÿÿÿÿÿ push 000025e9
[00002611] e8b3efffffÿÿÿÿÿÿ call 000015c9
[00002616] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[00002619] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
[0000261a] 68e7070000ÿÿÿÿÿÿ push 000007e7
[0000261f] e8e5e1ffffÿÿÿÿÿÿ call 00000809
[00002624] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
[00002627] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
[00002629] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[0000262a] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Size in bytes:(0034) [0000262a]
ÿÿSÿ machineÿÿ stackÿÿÿÿ stackÿÿÿÿ machineÿÿÿÿÿÿÿÿÿ assembly
ÿÿIÿ addressÿÿ addressÿÿ dataÿÿÿÿÿ codeÿÿÿÿÿÿÿÿÿÿÿÿ language
ÿÿMÿ (before)ÿ (after)ÿÿ (after)
ÿÿ=ÿ ========ÿ ========ÿ ========ÿ ===============ÿ =============
ÿÿÿ [00002609][0010400b][00000000] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
ÿÿÿ [0000260a][0010400b][00000000] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
ÿÿÿ [0000260c][00104007][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
ÿÿÿ [00002611][00104003][00002616] e8b3efffffÿÿÿÿÿÿ call 000015c9ÿÿ ;
_HHH1
ÿÿÿ New slave_stack at:1040af
Begin Local Halt Decider Simulationÿÿ Execution Trace Stored at:1140b7
[1][000025e9][001140a7][001140ab] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[1][000025ea][001140a7][001140ab] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[1][000025ec][001140a3][001040af] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[1][000025ed][0011409f][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
[1][000025f2][0011409b][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
[1]New slave_stack at:14ead7
[1]
Begin Local Halt Decider Simulationÿÿ Execution Trace Stored at:15eadf
[2][000025e9][0015eacf][0015ead3] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[2][000025ea][0015eacf][0015ead3] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[2][000025ec][0015eacb][0014ead7] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[2][000025ed][0015eac7][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
[2][000025f2][0015eac3][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
[2]New slave_stack at:1994ff
[3][000025e9][001a94f7][001a94fb] 55ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ebp
[3][000025ea][001a94f7][001a94fb] 8becÿÿÿÿÿÿÿÿÿÿÿÿ mov ebp,esp
[3][000025ec][001a94f3][001994ff] 51ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push ecx
[3][000025ed][001a94ef][000025e9] 68e9250000ÿÿÿÿÿÿ push 000025e9
[3][000025f2][001a94eb][000025f7] e8e2f7ffffÿÿÿÿÿÿ call 00001dd9ÿÿ ; _HHH
[1]CompareFunctions:
[1]ÿ Addr1 = 25f2
[1]ÿ Addr2 = 25f2
[1]ÿ Returning Addr2 = 1
[1]CompareFunctions:
[1]ÿ Addr1 = 1dd9
[1]ÿ Addr2 = 1dd9
[1]ÿ Returning Addr2 = 1
[1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[1][000025f7][001140a3][001040af] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
[1][000025fa][001140a3][00000000] 8945fcÿÿÿÿÿÿÿÿÿÿ mov [ebp-04],eax
[1][000025fd][001140a3][00000000] 837dfc00ÿÿÿÿÿÿÿÿ cmp dword [ebp-04],+00
[1][00002601][001140a3][00000000] 7402ÿÿÿÿÿÿÿÿÿÿÿÿ jz 00002605
[1][00002605][001140a7][001140ab] 8be5ÿÿÿÿÿÿÿÿÿÿÿÿ mov esp,ebp
[1][00002607][001140ab][0000167e] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
[1][00002608][001140af][0003a980] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
ÿÿÿ [00002616][0010400b][00000000] 83c404ÿÿÿÿÿÿÿÿÿÿ add esp,+04
ÿÿÿ [00002619][00104007][00000001] 50ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ push eax
ÿÿÿ [0000261a][00104003][000007e7] 68e7070000ÿÿÿÿÿÿ push 000007e7
ÿÿÿ [0000261f][00104003][000007e7] e8e5e1ffffÿÿÿÿÿÿ call 00000809ÿÿ ;
VMI:ÿ _Output
ÿÿÿ HHH1(DD)ÿÿÿ ---> 1
ÿÿÿ [00002624][0010400b][00000000] 83c408ÿÿÿÿÿÿÿÿÿÿ add esp,+08
ÿÿÿ [00002627][0010400b][00000000] 33c0ÿÿÿÿÿÿÿÿÿÿÿÿ xor eax,eax
ÿÿÿ [00002629][0010400f][00000018] 5dÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pop ebp
ÿÿÿ [0000262a][00104013][00000000] c3ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ret
Number of Instructions Executed(435547) == 6501 Pages
Summary:
HHH1[0] does not detect "Infinite Recursion".ÿ Instead, HHH1[1]
detects it [Observe simulation depth of "Infinite Recursion Detected"
message.] So HHH1[1] returns 0 to DD[1], and DD[1] halts.ÿ That is
detected by HHH[0], which decides DD halts.ÿ (This is the correct
halting decision.)
*IMPORTANT NOTE* : CompareFunctions() is only called twice, just as
for Test 1, but in this case it is HHH[1] making the calls rather than
HHH[0].ÿÿÿ *Both comparisons are comparing IDENTICAL addresses*, the
same addresses compared in Test 1.
========================
*Third test* :
At this point I intended to change CompareFunctions() to include the
HHH/HHH1 equivalency logic, but from Tests 1 and 2 it is clear that
will make no difference, so I can't be bothered! :)ÿ For both the
previous tests the only comparisons performed are for exactly equal
addresses, so the result will not be changed by including function
equivalency logic.
========================
*Forth and Fifth tests* :
These wouldÿ be running *MJT_HHH(MJT_DD)* and *MJT_HHH1(MJT_DD)* from
main.ÿ These are essentially versions of PO functions, but pure code
examples (no misuse of shared global data).ÿ Again they would use the
same CompareFunctions() as previous tests, effectively just logging
the address comparisons.
These two traces would match each other, both deciding that MJT_DD
never halts.ÿ Essentially they will be like the HHH(DD) trace (Test
1), with MJT_HHH[0] and MJT_HHH1[0] each detecting "Infinite
Recursion" and deciding MJT_DD doesn't halt.ÿ Conclusion would be that
the problem with PO's code is the misuse of global data.ÿ [...not the
address comparison issue...]
But this post is surely already too long!ÿ [I'd be happy to post Tests
4&5 if anyone wants to see them.]
Mike.
The whole point that Kaz pretends is over his head is:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
that never stops running until aborted
HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
(when HHH(DD) sees the repeating pattern)
The dumbest person here should have gotten
that three years ago.
Only one person ever got that and he did get
that three years ago.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 11/24/2025 8:15 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <NoOne@NoWhere.com> wrote:
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
That is the key difference
But that difference in the run-time of the system you have built is
propped up by bugs:
That is the kind of: "reckless disregard for the truth"
that loses libel cases.
- relying on mutable static state, of which HHH and HHH1 have their own
ÿÿ instance.
Is certainly not any kind of bug what-so-ever.
That statement is the kind of:
"reckless disregard for the truth"
that loses libel cases.
- comparing function addresses as the basis of equality and inequality
Is exactly how one can tell that the same function
has been called from the same address at the x86
level of semantics.
- ...
That is the key difference
If you properly coded HHH1 and HHH as pure functions that are identical,
and compared equal even if they have different addresses, then there
would be no difference between HHH(DD) and HHH1(DD).
I don't fully understand its analysis yet ChatGPT
seems to show how the static data can be implemented
using different segments of the Turing Machine tape. https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496
On 24/11/2025 22:45, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
For HHH/HHH1 the issue is different - they are clearly different
algorithms since they give
different results, but it's not pointer comparison that is the
problem - it's the use of mutable
global data:ÿ HHH and HHH1 each use /their own/ global variable [viz
their global trace tables]
within their algorithms.
Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
functions since they react to this mutating state.
Multiplie instances of HHH share an execution trace buffer, allocated
by the first call to HHH.
Multiple instances of HHH1 also share an execution trace buffer distinct
from that one allocated by the first call to HHH1.
Simulations conducted by any level of HHH only feed HHH's buffer,
and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
Exactly.ÿ That explains why HHH and HHH1 are not proper clones of each
other [whatever PO claims], and hence why they produce different results.
On 11/25/2025 1:19 PM, Mike Terry wrote:
On 24/11/2025 22:45, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
For HHH/HHH1 the issue is different - they are clearly different
algorithms since they give
different results, but it's not pointer comparison that is the
problem - it's the use of mutable
global data:ÿ HHH and HHH1 each use /their own/ global variable [viz
their global trace tables]
within their algorithms.
Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
functions since they react to this mutating state.
Multiplie instances of HHH share an execution trace buffer, allocated
by the first call to HHH.
Multiple instances of HHH1 also share an execution trace buffer distinct >>> from that one allocated by the first call to HHH1.
Simulations conducted by any level of HHH only feed HHH's buffer,
and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
Exactly.ÿ That explains why HHH and HHH1 are not proper clones of each
other [whatever PO claims], and hence why they produce different results.
So you are really trying to get away with pretending
to be too stupid that you have no idea that recursive
simulation defines behavior that cannot terminate normally?
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Simulating termination analyzer HHH and input DD
have been a fully operational software system for
more than three years.
**Conclusion:**
HHH is Turing computable, just not a pure function.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 14 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 116:45:59 |
| Calls: | 184 |
| Files: | 21,502 |
| Messages: | 81,790 |