Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2

On 15/07/2024 09:59, joes wrote:

Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:

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:

 

[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??)

Thank you. I didn't bother digging through their code, and they refused
to give the abortion criterion.
 

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

Ah, and here I believed them when they said they had rewritten it.

I doubt he has done it properly if at all.  I.e. I'm confident there will still be mutable static data giving different code paths for outer/inner executions.
I offered to help PO sort out the required recursive logic but this was ignored, PO saying it would take him thousands of years(?) to do it correctly.  I reckon anyone else here would fix it in a couple of hours!

 

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

I wondered about just calling the same function repeatedly with the same
parameters (on the same simulation level).

Right, I see.  Like:
void Something () {}
void DDD ()
{
   for (int i=0; i<10; ++i)
   {
     Something ();
   }
}
That wouldn't match.  The calls to Something() would match the CALL conditions, but the final test for conditional instructions would fail due to the presence of a conditional branch in the for() loop.
I'm sure there are other reasonably simple examples which could expose problems but its pointless thinking them up, because PO will just add more conditions to explainn why they don't count, or in the end just ignore such examples (giving some incoherent or blatently wrong explanation), because he simply believes that what he claims is correct.  (Regardless of any logic applied to the situation...  PO /can't/ be persuaded by logic, because he just doesn't see logic [neural wiring issue?] - notice how not one of his "proofs" contain a shred of genuine logic where conclusions genuinely follow from what was said previously - they are all just PO restating his claims over and over with increasingly misleading wording!  For sure he sees other peoples proofs, and tries to ape the features of those proofs [introducing fancy symbols and techy-sounding words] but it is all a case of form over genuine substance.)
Mike.

 

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.

It's just that the input HHH halts and does not need to be aborted.

Ah, if only someone had thought to tell PO this 2 years ago!! :)