Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: DDD correctly emulated by HHH is Correctly rejected as
 non-halting V2
Date: Mon, 15 Jul 2024 08:59:36 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <aa7643b6d8c46d2c4dd5ef92ae3650afe114adbb@i2pn2.org>
References: <v6rg65$32o1o$3@dont-email.me>
	<97e0632d0d889d141bdc6005ce6e513c53867798@i2pn2.org>
	<v6sdlu$382g0$1@dont-email.me> <v6td3a$3ge79$1@dont-email.me>
	<v6tp1j$3imib$2@dont-email.me> <v6trdu$3irhh$1@dont-email.me>
	<v6tu01$3imib$11@dont-email.me>
	<a177dd76613794d6bb877c65ffe6c587a8f31bc1@i2pn2.org>
	<v6tvpv$3imib$14@dont-email.me>
	<091e8b7baeea467ee894b1c79c8943cb9773adb7@i2pn2.org>
	<v6u346$3khl8$1@dont-email.me>
	<16ac79611a441e7e01119631051f69119eee958a@i2pn2.org>
	<v6v06i$3pivt$1@dont-email.me>
	<23cb2d2401b87bf4f6a604aa1a78b93ffc9a29bc@i2pn2.org>
	<v6v2t1$3pmjn$3@dont-email.me>
	<3fc6548531f91ed14a27420caf9679a634573ed0@i2pn2.org>
	<v70lmo$61d8$1@dont-email.me>
	<8a6e6d9ff49aabe2525ce5729a439c807de4768a@i2pn2.org>
	<34Ocnd4voeWlDAn7nZ2dnZfqnPudnZ2d@brightview.co.uk>
	<v725d7$hlvg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 15 Jul 2024 08:59:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3346128"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 6147
Lines: 90

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.

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

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

-- 
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.