On 7/14/24 11:35 PM, olcott wrote:
On 7/14/2024 10:02 PM, Mike Terry wrote:
On 15/07/2024 01:20, joes wrote:
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Can you elaborate? All runtime instances share the same static code. >>>>>>> I am talking about the inner HHH which is called by the simulated >>>>>>> DDD. That one is, according to you, aborted. Which is wrong, because >>>>>>> by virtue of running the same code, the inner HHH aborts ITS
simulation of DDD calling another HHH.
What are the twins and what is their difference?
Do you disagree with my tracing?
The directly executed DDD is like the first call of infinite recursion. >>>> The emulated DDD is just like the second call of infinite recursion.
When the second call of infinite recursion is aborted then the first
call halts.
Not really. Execution does not continue.
void Infinite_Recursion()
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing
Infinite_Recursion() to halt.
That would be incorrect.
When DDD calls HHH(DDD) HHH returns.
Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is proven >>>> below. The executed DDD() has HHH(DDD) skip this call.
I do not see this below.
HHH(DDD) must skip this call itself by terminating the whole DDD
process.
Because this HHH does not know its own machine address HHH only sees
that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To
HHH it
looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>> New slave_stack at:14e2ec -- create new process context for 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
How is this detected?
PO seems not to want to answer you, as I notice you've asked this
question more than once and PO dodges a direct response, so I'll try.
(Alternatively, PO has provided a link to his source code in the past,
so if you can find that link you can just look the answer yourself -
the functions are all in his halt7.c file, which is compiled but not
linked, then the obj file is interpreted within his x86utm.exe (source
also given in the link. The link might not reflect his current code??)
Anyhow, this is what I reckon...
HHH [outer HHH only!] examines a global trace table of simulated
instruction (from all simulation levels merged together). The
particular message "Infinite Recursion Detected Simulation Stopped"
seems to be issued when:
- last instruction is a CALL
- working backwards through the merged trace table, another CALL is
encountered
- ..which is issued at the same address
- ..and is calling to the same address
- ..and no "conditional branch" instructions occur in the trace table
between the two call instructions
KEY TO NOT BEING MISLED BY THE ABOVE:
0. The "Infinite Recursion Detected Simulation Stopped" message is
just a printf.
It does not prove that /actual/ infinite recursion was detected -
on the contrary,
all here but PO realise that the recursion detected is just finite
recursion.
1. The trace table being examined is NOT an x86 processor trace - it is a
"merged simulation trace" containing entries for ALL SIMULATION
LEVELS.
So the two CALL instructions are not referring to one single x86
processor.
When emulated DDD calls HHH(DDD) the outer HHH emulates itself
emulating DDD.
I think that joes does not understand these things.
Typically, the last call instruction is from a deeper nested
simulation
than the earlier detected call instruction. The outer simulations >> are all
still running, but do not appear in the trace table or logs
presented by PO
due to the next note.
2. The searched trace table is filtered to only contain instructions
within the C
function D/DD/DDD/.. !!
YES, YOU READ THAT RIGHT! ALL CODE IN HHH IS TOTALLY IGNORED,
INCLUDING
THE CONDITIONAL BRANCH INSTRUCTIONS THAT ARE TESTING THE VERY
ABORT TESTS
THAT CAUSE OUTER HHH TO ABORT.
3. Inner HHH's do not perform the same tests as above, because they
inspect a global
variable which tells them they are inner HHH's. Yeah, that means
the simulation
is completely broken logically... [but... the outer HHH will abort
first, so
PO might argue the outcome will be the same, even though logically
it is
broken...]
Is it also triggered when calling a function
in a loop?
Not sure what you mean. Calling a function in a loop ends if the loop
ends, right? What loop are you thinking of?
Anyhow, provided the call instructions are physically located in
function D() [i.e. not H() or something called from H] I guess it
would match. But the C function D has only one call instruction,
which isn't in a loop!
Regards,
Mike.
*I have boiled it all down to this simple tautology*
Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.
And since the input to the HHH that aborts and returns (which includes
ALL the code of that input, including the HHH that it calls) can be
given to a pure simumlator that doesn't abort, and it will reach the end
of the program, this HHH (which DOES abort) didn't NEED to abort.
You are just ignorant of the immutability and determinism properties of programs.
Computation problems are ALWAYS Objective questions whose answer does
not depend on what version of a decider or which decider you ask about
that input. YOu r POOP problem fails to meet that requirement, as the
behavior of the program fragment DDD depends on behavior of the decider
it is given to, and thus is not a valid Compution problem, and you have
been wasting you life trying to convince people that your POOP, a
problem outside of Computation Theory somehow overrides the PROVEN
answer of a question in computation theory.
Just like all you Red Herrings that have nothing to do with the original question, your POOP has nothing to do with how Halting is defined or determined.
You have just wasted your life by lying to yourself and beleiving your
own lies.
Sorry, but that is just simple Truth.
And this applies to you ideas more generally. By you not understanding
how Logic works, you have been lying to yourself about your ideas of
Truth and Knowledge, and that has left you with a great big bag of
nothing but POOP, which no one wants. Perhaps, if the weren't ruined by
their association with POOP, some of your ideas of "correct reasoning"
might have been able to go somewhere, but they have been filled with
POOP and are now worthless and no one will touch it with a 39 1/2 foot pole.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)