On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the relevant
citations from ISO/IEC 9899.
HHH1 and HHH are identical except for their names per diff.
HHH(DDD) and HHH1(DDD) have provable different execution traces
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021a3][0010382d][00000000] 55 push ebp ; main() [000021a4][0010382d][00000000] 8bec mov ebp,esp ; main() [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD [000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9 [00002183][001138c9][001138cd] 55 push ebp ; DDD of HHH1
[00002184][001138c9][001138cd] 8bec mov ebp,esp ; DDD of HHH1 [00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301 [00002183][0015e2f1][0015e2f5] 55 push ebp ; DDD of HHH[0]
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp ; DDD of HHH[0]
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD [0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
[00002183][001a8d19][001a8d1d] 55 push ebp ; DDD of HHH[1]
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp ; DDD of HHH[1]
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002190][001138c9][001138cd] 83c404 add esp,+04 ; DDD of HHH1 [00002193][001138cd][000015a8] 5d pop ebp ; DDD of HHH1
[00002194][001138d1][0003a980] c3 ret ; DDD of HHH1
[000021b0][0010382d][00000000] 83c404 add esp,+04 ; main() [000021b3][0010382d][00000000] 33c0 xor eax,eax ; main() [000021b5][00103831][00000018] 5d pop ebp ; main() [000021b6][00103835][00000000] c3 ret ; main()
Number of Instructions Executed(352831) == 5266 Pages
I thought you fancied yourself a C expert, or at least someone who
knows what C experts know? *Any* C programmer, even a rank newbie,
knows that DD is DD and vice versa.
Kaz addressed this at the mathematics at the theory of
computation level
On 8/12/2025 2:50 PM, Kaz Kylheku wrote:
If you're trying to demonstrate your work using
stateful procedures, you must be explicit about
revealing the state, and ensure that two instances
of a computations which you are identifying as
being of the same computation have exactly the
same initial state, same inputs, and same subsequent
state transitions. You cannot call two different
computations with different state transitions "DD"
and claim they are the same.
So DD correctly emulated by HHH and the directly
executed DD() are two distinctly different entities.
Whereas DD correctly emulated by HHH1 and the directly
executed DD() are the same entity.
DD emulated by HHH emulates the initial sequence of
instructions of DD one more time that HHH1 does as
I have just proven again in another reply using DDD.
That was his brilliant insight into the matter.
I'll leave that one for Kaz to answer if he wishes.
On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD
promptly halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the
relevant citations from ISO/IEC 9899.
HHH1 and HHH are identical except for their names per diff.
HHH(DDD) and HHH1(DDD) have provable different execution traces
On 8/16/25 8:36 AM, olcott wrote:
On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD
promptly halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the
relevant citations from ISO/IEC 9899.
Where?
Which version?
On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the relevant
citations from ISO/IEC 9899.
HHH1 and HHH are identical except for their names per diff.
HHH(DDD) and HHH1(DDD) have provable different execution traces
On 16/08/2025 14:03, Richard Damon wrote:
On 8/16/25 8:36 AM, olcott wrote:
On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD promptly
halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the
relevant citations from ISO/IEC 9899.
Where?
Which version?
These quotations are taken from ISO/IEC 9899:1999, but I'd be astonished
if you were to find significant differences in later versions.
A function definition includes the function body. 6.7(5)
The identifier declared in a function definition (which is the name of
the function) shall have a function type, as specified by the declarator portion of the function definition. 6.9.1(2)
A function designator is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary &
operator, a function designator with type ‘‘function returning type’’ is
converted to an expression that has type ‘‘pointer to function returning type’’. 6.3.2.1(4).
HHH(DD) specifies a function designator whose termination status is to
be investigated. That designator is (as outlined above) converted to a pointer. It's how you tell which function to emulate.
HHH is reporting on DD, because you ask it to. And the function that
does the asking is DD. The DD in HHH(DD) and the DD in int DD() are one
and the same DD. Not because I say so, but because C says so.
Don't take my word for it. Ask any C expert. Kaz, for example, or Keith.
There is only one DD.
Recursion can let you have multiple instances of a function, and each
even has its own locals, but they are the same function, and it is the *function*, not a mere instance, that HHH has been asked to assess.
On 8/16/2025 8:21 AM, Richard Heathfield wrote:
On 16/08/2025 13:36, olcott wrote:
On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD promptly
halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the
relevant citations from ISO/IEC 9899.
HHH1 and HHH are identical except for their names per diff.
HHH(DDD) and HHH1(DDD) have provable different execution traces
So? That doesn't change the rules of the language. Or do you now claim
that ISO is trying to gaslight you?
<snip>
No halt decider ever reports on anything besides
the behavior that its input actually specifies.
[the naive halting problem is now corrected]
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data. I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
On 8/16/2025 2:00 PM, André G. Isaak wrote:
On 2025-08-16 11:05, olcott wrote:counter-factual. No other function can see it is it is not global.
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state, make sureIt is not a global state. It is functionally equivalent to local
you make that explicit. Include a routine which initializes the
global state.
static data. I figured that slave instances of a UTM could share data
with their master UTM on the basis of shared tape space.
If something is declared as static, then it *is* a global state.
André
On 8/16/25 9:40 AM, Richard Heathfield wrote:
There is only one DD.But, when you look at the definition of the BEHAVIOR of code as a
Recursion can let you have multiple instances of a function,
and each even has its own locals, but they are the same
function, and it is the *function*, not a mere instance, that
HHH has been asked to assess.
program, you need to include all the routines called.
The C standard never talks about the "behavior" of a function
that calls something not defined.
It talks about the behavior of each piece of code, but the
combined behavior is dependent on the HHH that is called,
IT is expicitly an error to have a call to code that isn't
included in the program or defined by the standard,
and
attempting to run code that has this problem is explicitly
undefined behavior.
Thus, the code for HHH must be included in the definition of the
program or its behavior is underined.
A big thing to note, The word "function" has different meanings
between Computation Theory and the C language,
DD Halts if HHH(DD) returns 0 or aborts and terminates the process.
DD does not halt if HHH(DD) returns 1 or doesn't return.
Of course, this analysis says that there is no HHH that returned
the right answer for the input DD.
On 8/16/2025 2:00 PM, André G. Isaak wrote:
On 2025-08-16 11:05, olcott wrote:
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data. I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
If something is declared as static, then it *is* a global state.
André
counter-factual. No other function can see it
is it is not global.
On 8/16/2025 2:46 PM, André G. Isaak wrote:
On 2025-08-16 13:03, olcott wrote:
On 8/16/2025 2:00 PM, André G. Isaak wrote:
On 2025-08-16 11:05, olcott wrote:
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data. I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
If something is declared as static, then it *is* a global state.
André
counter-factual. No other function can see it
is it is not global.
Why don't you try to explain the difference between a global variable
and a static local variable in the compiled x86 code -- hint, there
isn't one. And you do keep claiming your "halt decider" takes x86 code
rather than C code.
André
I am just calling out your mistake.
There is a difference at the C level
and when all the x86 code is generated
from a C compiler this difference remains.
On 8/16/2025 3:05 PM, André G. Isaak wrote:
On 2025-08-16 13:52, olcott wrote:OK. I don't mind being corrected when I am wrong.
On 8/16/2025 2:46 PM, André G. Isaak wrote:
On 2025-08-16 13:03, olcott wrote:I am just calling out your mistake.
On 8/16/2025 2:00 PM, André G. Isaak wrote:
On 2025-08-16 11:05, olcott wrote:counter-factual. No other function can see it is it is not global.
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state, makeIt is not a global state. It is functionally equivalent to local >>>>>>> static data. I figured that slave instances of a UTM could share >>>>>>> data with their master UTM on the basis of shared tape space.
sure you make that explicit. Include a routine which initializes >>>>>>>> the global state.
If something is declared as static, then it *is* a global state.
André
Why don't you try to explain the difference between a global variable
and a static local variable in the compiled x86 code -- hint, there
isn't one. And you do keep claiming your "halt decider" takes x86
code rather than C code.
André
There is a difference at the C level and when all the x86 code is
generated from a C compiler this difference remains.
You're confusing global states with global scope. They're not the same
thing. Static local variables are allocated globally whereas automatic
variables are allocated on the stack.
André
I really hate it when I am being corrected on the basis of someone
else's misconception.
This is especially annoying when I correct them on this and they never
pay any attention to any of my words of correction and this repeats over
and over.
On 8/16/2025 3:32 PM, Mr Flibble wrote:
On Sat, 16 Aug 2025 15:20:00 -0500, olcott wrote:
On 8/16/2025 3:05 PM, André G. Isaak wrote:
On 2025-08-16 13:52, olcott wrote:OK. I don't mind being corrected when I am wrong.
On 8/16/2025 2:46 PM, André G. Isaak wrote:
On 2025-08-16 13:03, olcott wrote:I am just calling out your mistake.
On 8/16/2025 2:00 PM, André G. Isaak wrote:Why don't you try to explain the difference between a global
On 2025-08-16 11:05, olcott wrote:counter-factual. No other function can see it is it is not global. >>>>>>
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:If something is declared as static, then it *is* a global state. >>>>>>>>
If you use impure functions that depend on global state, make >>>>>>>>>> sure you make that explicit. Include a routine whichIt is not a global state. It is functionally equivalent to local >>>>>>>>> static data. I figured that slave instances of a UTM could share >>>>>>>>> data with their master UTM on the basis of shared tape space. >>>>>>>>
initializes the global state.
André
variable and a static local variable in the compiled x86 code --
hint, there isn't one. And you do keep claiming your "halt decider" >>>>>> takes x86 code rather than C code.
André
There is a difference at the C level and when all the x86 code is
generated from a C compiler this difference remains.
You're confusing global states with global scope. They're not the
same thing. Static local variables are allocated globally whereas
automatic variables are allocated on the stack.
André
I really hate it when I am being corrected on the basis of someone
else's misconception.
This is especially annoying when I correct them on this and they never
pay any attention to any of my words of correction and this repeats
over and over.
DD() does the opposite of what HHH(DD) reports ergo the Halting Problem
is undecidable.
/Flibble
DD correctly simulated by HHH at least gets stuck in recursive
simulation thus DD() still never reaches the point of doing the opposite
of anything.
On 2025-08-16, olcott <[email protected]> wrote:
On 8/15/2025 11:35 PM, Richard Heathfield wrote:
On 16/08/2025 04:46, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
As C indicates, they're the same DD. I've already posted the relevant
citations from ISO/IEC 9899.
HHH1 and HHH are identical except for their names per diff.
HHH(DDD) and HHH1(DDD) have provable different execution traces
Then that means HHH1 a.k.a HHH isn't a function. It is a procedure
with side effects. Those side effects cause it to have different
visible results when given the same argument.
That means you cannot use them as the basis of function-based
arguments around halting.
The comptuation of a Turing machine is equivalent to
a recursive calculation by a pure function.
Either use Turing machines with their tapes and all, or
use pure functions.
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
If you have global state and recursion you need to have
a mechanism to save, reset and restore the global state,
and make it explicit everywhere.
For instance, rather than
HHH(DD)
you need:
hhh_state_t state = HHH_save(); // returns all global state
HHH_reset();
int result = HHH(DD);
HHH_restore(state); // back to as if reset and HHH call didn't happen
Then HHH(DD) inside DD is fresh, like the one in main, provided that HHH_reset() brings about the same initial state like the one found at
program startup.
On 8/16/2025 2:00 PM, André G. Isaak wrote:
On 2025-08-16 11:05, olcott wrote:
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data. I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
If something is declared as static, then it *is* a global state.
André
counter-factual. No other function can see it
is it is not global.
On 8/16/2025 2:00 PM, André G. Isaak wrote:
On 2025-08-16 11:05, olcott wrote:
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data. I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
If something is declared as static, then it *is* a global state.
André
counter-factual. No other function can see it
is it is not global.
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data.
I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
If you have global state and recursion you need to have
a mechanism to save, reset and restore the global state,
and make it explicit everywhere.
lines 1081 to 1156 make this explicit https://github.com/plolcott/x86utm/blob/master/Halt7.c
u32* execution_trace; // is the only data I need to share
u32* Aborted; // looks like it is shared but it is not
The function that uses that variable has been switched to
line 1040: u32 aborted_temp = 0; // 2024-06-05
For instance, rather than
HHH(DD)
you need:
hhh_state_t state = HHH_save(); // returns all global state
HHH_reset();
int result = HHH(DD);
HHH_restore(state); // back to as if reset and HHH call didn't happen
Then HHH(DD) inside DD is fresh, like the one in main, provided that
HHH_reset() brings about the same initial state like the one found at
program startup.
If the master UTM cannot receive the execution_trace data
from shared space on the master UTM tape then it cannot
see that itself is being called in recursive simulation.
On 8/17/2025 2:05 AM, Kaz Kylheku wrote:See above: it is shared between different invocations.
On 2025-08-16, olcott <[email protected]> wrote:
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
Local static data is shared among multiple instances of the sameMy static data is homemade. I directly embedded the pointer to execution_trace in the function body.
function. It is non-local, and therefore global.
We don't call it global because of scope; scope is just a scoping
matter having to do with resolution of names, controlling their
visibility.
Under the hood, static data is transformed by the compiler into
anonymized global data. In many compiler toolchains you can see statics
in the object file symbol table, under funny names.
For the purposes of disussions about function purity, halting and all
that, statics are the same as globals.
No other C function can possibly access this data at the C level.
HHH can tautologically see what it simulates.The only data they can legitimate share is immutable data such asIn the essential design of HHH(DD) HHH merely needs to see all of the behavior of DD correctly simulated by HHH including HHH simulating an instance of itself simulating an instance of DD.
program iterals. If one UTM is changing something and antoher one is
reading it, you have a problem.
The actual behavior of DD correctly simulated by HHH does seem to be aNo, because HHH detects if it is being simulated.
pure function of the input to HHH(DD).
Mike Terry did seem to say that there is a way for HHH to see this*Turing
behavior that does not need a static pointer to execution_trace.
You cannot have a Turning machine sharing tape (a machine with multiple
heads going over the same tape) while continuing to make arguments on
the basis of all those tape heads being separate, independent Turning
machines.
Then we could simply construe them as aspects of the same computation.No, it does change whether HHH aborts. That’s why you put it there!
There is only one executing HHH. The rest are data that this HHH is
playing with.
Your Init_Halts returns a 0 or 1 "Root" value, which changes subsequentThis has no effect on the execution trace that remains DD correctly
behavior of HHH, due to being used for making decisions in
Decide_Halting_HH.
simulated by HHH cannot possibly reach its own "return" statement final
halt state. It is merely an aspect of HHH being able to see this full
trace.
That’s not necessary; HHH has access to everything anyway.In HHH, you reserve some bytes at the start of the function that areThat has no effect on the actual trace of DD correctly simulated by HHH.
filled four NOP, 0x90. So if the execution_trace points to HHH's
instructions, those four bytes can be seen there.
DD doesn't have those bytes.
It merely provides the means for the directly executed HHH to see this
full execution trace.
Where and what for is that checked?More troublingly, you also code which /writes/ through theThat indicates that memory has not yet been allocated for the execution_trace.
execution_trace pointer to store four NOPs (0x90909090):
*execution_trace = 0x90909090;
It’s still shared between different invocations.HHH(DD) cannot be overwriting instructions of DD, what the actualHHH is not overwriting the instructions of DD.
hell???
HHH is overwriting a portion of itself to make homemade static data that
is not global.
Which HHH?you need:If the master UTM cannot receive the execution_trace data from shared
hhh_state_t state = HHH_save(); // returns all global state
HHH_reset();
int result = HHH(DD);
HHH_restore(state); // back to as if reset and HHH call didn't
happen
Then HHH(DD) inside DD is fresh, like the one in main, provided that
HHH_reset() brings about the same initial state like the one found at
program startup.
space on the master UTM tape then it cannot see that itself is being
called in recursive simulation.
A machine must not "see" anything of the sort. Its only input is the
test case to be decided and not any other information about the
circumstances of the nesting or whatever else.
*So HHH(DD)==0 even if HHH does not know it*
On 8/17/2025 2:05 AM, Kaz Kylheku wrote:
On 2025-08-16, olcott <[email protected]> wrote:
On 8/16/2025 11:34 AM, Kaz Kylheku wrote:
If you use impure functions that depend on global state,
make sure you make that explicit. Include a routine which
initializes the global state.
It is not a global state. It is functionally equivalent
to local static data.
Local static data is shared among multiple instances of the same
function. It is non-local, and therefore global.
We don't call it global because of scope; scope is just a scoping matter
having to do with resolution of names, controlling their visibility.
Under the hood, static data is transformed by the compiler into
anonymized global data. In many compiler toolchains you can see statics
in the object file symbol table, under funny names.
My static data is homemade. I directly embedded the
pointer to execution_trace in the function body.
No other C function can possibly access this data
at the C level.
For the purposes of disussions about function purity, halting and all
that, statics are the same as globals.
https://en.wikipedia.org/wiki/Pure_function
(For the purposes of software engneering where we are concerned with the
good organization of a large program, we think about them differently,
because the reduced visibility of statics is relevant.)
I figured that slave instances
of a UTM could share data with their master UTM on
the basis of shared tape space.
The only data they can legitimate share is immutable data such as
program iterals. If one UTM is changing something and antoher one is
reading it, you have a problem.
In the essential design of HHH(DD) HHH merely needs to
see all of the behavior of DD correctly simulated by HHH
including HHH simulating an instance of itself simulating
an instance of DD.
The actual behavior of DD correctly simulated by HHH
does seem to be a pure function of the input to HHH(DD).
Mike Terry did seem to say that there is a way for
HHH to see this behavior that does not need a static
pointer to execution_trace.
You cannot have a Turning machine sharing tape (a machine with
multiple heads going over the same tape) while continuing to make
arguments on the basis of all those tape heads being separate,
independent Turning machines.
Then we could simply construe them as aspects of the same
computation. There is only one executing HHH. The rest are
data that this HHH is playing with.
If you have global state and recursion you need to have
a mechanism to save, reset and restore the global state,
and make it explicit everywhere.
lines 1081 to 1156 make this explicit
https://github.com/plolcott/x86utm/blob/master/Halt7.c
u32* execution_trace; // is the only data I need to share
u32* Aborted; // looks like it is shared but it is not
The function that uses that variable has been switched to
line 1040: u32 aborted_temp = 0; // 2024-06-05
Your Init_Halts returns a 0 or 1 "Root" value, which changes
subsequent behavior of HHH, due to being used for making
decisions in Decide_Halting_HH.
This has no effect on the execution trace that remains
DD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. It is merely
an aspect of HHH being able to see this full trace.
In HHH, you reserve some bytes at the start of the function that are
filled four NOP, 0x90. So if the execution_trace points to HHH's
instructions, those four bytes can be seen there.
DD doesn't have those bytes.
That has no effect on the actual trace of DD correctly
simulated by HHH. It merely provides the means for the
directly executed HHH to see this full execution trace.
More troublingly, you also code which /writes/ through the
execution_trace pointer to store four NOPs (0x90909090):
*execution_trace = 0x90909090;
That indicates that memory has not yet been allocated
for the execution_trace.
If the function has not reserved four bytes of space,
you are overwriting its legitimate instructions with NOPs.
This space was already set aside for that purpose.
The code uses goto SKIP; to jump over this embedded data.
HHH(DD) cannot be overwriting instructions of DD, what the
actual hell???
HHH is not overwriting the instructions of DD.
HHH is overwriting a portion of itself to make
homemade static data that is not global.
For instance, rather than
HHH(DD)
you need:
hhh_state_t state = HHH_save(); // returns all global state
HHH_reset();
int result = HHH(DD);
HHH_restore(state); // back to as if reset and HHH call didn't
happen
Then HHH(DD) inside DD is fresh, like the one in main, provided that
HHH_reset() brings about the same initial state like the one found at
program startup.
If the master UTM cannot receive the execution_trace data
from shared space on the master UTM tape then it cannot
see that itself is being called in recursive simulation.
A machine must not "see" anything of the sort. Its only input
is the test case to be decided and not any other information
about the circumstances of the nesting or whatever else.
Whether or not HHH can see DD simulated by HHH
including HHH simulating an instance of itself
simulating an instance of DD,
DD correctly simulated by HHH cannot possibly reach
its own "return" statement final halt state as a pure
function of the input to HHH(DD).
*So HHH(DD)==0 even if HHH does not know it*
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:01:08 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,550 |