Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Tue, 13 May 2025 18:46:30 +0100
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <10000hl$1v330$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me>
 <87msbmeo3b.fsf@nosuchdomain.example.com> <vvjcge$27753$2@dont-email.me>
 <vvjeqf$28555$1@dont-email.me> <vvjffg$28g5i$1@dont-email.me>
 <875xiaejzg.fsf@nosuchdomain.example.com> <vvjgt1$28g5i$5@dont-email.me>
 <87jz6qczja.fsf@nosuchdomain.example.com> <vvjotc$28g5i$12@dont-email.me>
 <vvnh9u$3hd96$1@raubtier-asyl.eternal-september.org>
 <vvno4e$3in62$2@dont-email.me> <vvo71c$rlt$1@news.muc.de>
 <PlNTP.270466$lZjd.128570@fx05.ams4> <vvochv$15td$2@news.muc.de>
 <vvodn5$3na6l$3@dont-email.me>
 <1276edeb9893085c59b02bbbd59fe2c64011736b@i2pn2.org>
 <vvqk4s$gldn$12@dont-email.me> <vvqln4$g8ck$5@dont-email.me>
 <vvrftj$ndkg$1@dont-email.me> <vvrima$nejb$3@dont-email.me>
 <vvua3t$1hm37$1@dont-email.me>
 <cd36dcf87daefa9ae472cc426d57704c2baa4292@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 13 May 2025 19:46:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="750d255cb0ee70f75da7805aef2899f4";
	logging-data="2067552"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+J5gxxl2T0JpmdWwWikxASh62L20ylTIg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:GIJzsIr1t58ORPFjMt1T5sxtqJg=
In-Reply-To: <cd36dcf87daefa9ae472cc426d57704c2baa4292@i2pn2.org>

On 13/05/2025 10:01, joes wrote:
> Am Tue, 13 May 2025 03:17:32 +0100 schrieb Mike Terry:
> 
>> When his HHH simulates DD, it spots a pattern in the simulation which PO
>> calls his "infinite recursive simulation" pattern.  PO believes that
>> this pattern "specifies non halting behaviour" but it does not, as it
>> can match for both halting and non-halting computations.  Anyhow, PO has
>> coded HHH to abort and return non-halting if it sees that pattern.  He
>> really really really believes that pattern "specifies non halting",
>> despite observing with his own eyes DD halting when called directly!
>> The rest of his arguments are just attempts to justify why HHH is
>> "correct" to decide non-halting, despite DD halting.  They generally
>> amount to something like "during simulation my HHH detected non-halting
>> behaviour, so it is correct to decide non-halting".
> 
> Can you remind me how it matches halting computations? IIRC it looks
> for invocations of the same function (across simulation levels, mind)
> without conditional statements inbetween. Or is the impossibility of
> recursive simulation the only reason for false positives?
> 

Recursive simulation is not itself the problem.  If we set aside some design errors like the use of 
mutable global data to communicate across simulation levels (making simulations follow a different 
code path to directly executed code), then in principle PO's x86utm could handle nested simulation 
in an ok way, at least for the purposes PO needs.  His x86utm itself does cater for simulating a 
simulation of a simulation and so on, at the instruction level.

Your description of the matching process is pretty much right - I'll need to check in halt7.c ...

Right, so the matching process goes like this:

-  simulated instructions (from all simulation levels) are added to a
    global trace table, but ONLY IF THEY ARE FROM DD, i.e. their address
    puts them physically inside C function DD.
    Trace entries from HHH and routines called from HHH are discarded.

-  when a call instruction is simulated the trace table is scanned backwards
    looking for a "matching" entry: that is, another call from the same
    address, and to the same target address.

-  if one is found, a check is made for whether there were any conditional
    branch instructions in the trace table between the matching calls
    [remember, the trace table only includes instructions inside C function DD]

-  if no conditional branches were encountered, the simulation is aborted
    with message "Infinite Recursion Detected Simulation Stopped\n\n",
    and the simulating HHH decides non-halting.

-  if no match is found, simulation continues as normal.

The global trace table does not record the simulation level for an entry, so the matching process is 
agnostic when it comes to simulation levels.   Also note there are many conditional branch 
instructions in HHH which would prevent matches occuring if we were to include HHH instructions in 
the examined trace!

For completeness, there is also a similar looking test relating to unconditional branches (jmp and 
the likes) aimed at detecting loops rather than recursion.  This test does not match for input DD.


Regards,
Mike.