Path: ...!Xl.tags.giganews.com!local-4.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 13 Aug 2024 03:09:47 +0000
Subject: Re: HHH maps its input to the behavior specified by it --- key error
 in all the proofs --- Mike
Newsgroups: comp.theory
References: <v8jh7m$30k55$1@dont-email.me> <v98uf7$vepo$1@dont-email.me>
 <60f1a533219c1237071f358999228eb48727f5e9@i2pn2.org>
 <v991tu$vepo$2@dont-email.me>
 <895f5e9b934bbfb72925fb109043500d49100a6a@i2pn2.org>
 <v994vs$10cfm$1@dont-email.me>
 <dec62801011bc5bf0b9eb9a62c607cf407198609@i2pn2.org>
 <v99870$14mlk$1@dont-email.me>
 <0f8f134fe961ee00910cce1d7f05b632d7567c6c@i2pn2.org>
 <v9abfu$2nabt$1@dont-email.me>
 <86c21e8a63450bf8b0c32f4f17ba0b503a914fe0@i2pn2.org>
 <v9d01i$39tbd$2@dont-email.me>
 <2c853efb65c3d8e2d4ba1c484f7002c74c68d895@i2pn2.org>
 <v9d1v8$3a9pe$1@dont-email.me>
 <e614d6b981fd5fa6eefc84894a14448d4663e3c7@i2pn2.org>
 <v9da2d$3bth4$1@dont-email.me>
 <64ddeeaa3a55a9e410de599bd8df53d3644ee5a3@i2pn2.org>
 <v9de0o$3cjse$1@dont-email.me> <v9dela$3cjse$2@dont-email.me>
 <b7c45ea22cb83908c31d909b67f4921156be52e3@i2pn2.org>
 <v9dgvl$3d1an$1@dont-email.me>
 <d289636b1d244acaf00108f46df093a9fd5aa27c@i2pn2.org>
 <v9dk2j$3dp9h$1@dont-email.me>
 <8318f5969aa3074e542747fe6ba2916d7f599bde@i2pn2.org>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Tue, 13 Aug 2024 04:09:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <8318f5969aa3074e542747fe6ba2916d7f599bde@i2pn2.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <TyKdnc3hCNvmUyf7nZ2dnZfqn_udnZ2d@brightview.co.uk>
Lines: 135
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-S53ZRNctSDuvdIEcdn8gmR2qBBRHq/8dswNukBICnOm/IgE4dZKvUbGNqttbVRgILnEw4Ki40aFS4FD!Z18O5/f20ZmzGxMr45yyLT9/AksulFtyqEa4ZNPMPnqgJqxF1yZ+i7H2ZcdH9sIjrIeaUhrRMxHW!8+958ujk6Dgvomvv2LtcoC9LsgQ=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 9940

On 12/08/2024 22:13, Richard Damon wrote:
> On 8/12/24 2:25 PM, olcott wrote:
>> On 8/12/2024 1:16 PM, Richard Damon wrote:
>>> On 8/12/24 1:32 PM, olcott wrote:
>>>> On 8/12/2024 12:12 PM, Richard Damon wrote:
>>>>> YOU don't understand the rules of the x86 code, or don't care if you are wrong, as NOTHING in 
>>>>> the x86 language allows the leaving of the direct exectuion thread and into showing the code 
>>>>> the simulator being simulated is simulating. The ONLY correct answer is showing it doing the 
>>>>> simulating.
>>>>>
>>>>
>>>> I showed the first four lines of this code
>>>> highlighted in red and you ignored it.
>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
> 
> First a few comments about this file.
> 
> It has clearlly changed over time without notice, you said you added highlighting, but it also has 
> had content changes.
> 
> It really needs to be date-stamped and version controlled. I can not say if the copy I look at today 
> is the same as I looked at the other day.
> 
> Second, it is NOT the trace you keep on claiming but is the trace that x86UTM makes of running main, 
> with the trace that the levels of HHH do inserted (WITHOUT COMMENT) into the listing, making the 
> trace that HHH generats hard to find.
> 
> The length of the wrong trace starts on page 38, so there are only about 160 pages of trace (the 
> rest is an assembly listing of the program, useful to understand the trace, but not part of the 
> trace itself) and there are only 1 to 2 lines from HHH per page, so a trace of just what HHH does 
> would be only about 200-300 LINES long, not 200 pages, and not beyond what many people can handle, 
> especially when you remove the cruft of having to wade through all the other junk that isn't the 
> trace that HHH makes.
> 
> There are also clearly functions that are not even correctly listed in the assembly listings, nor 
> traced, that seem to be hooks to make OS calls. That isn't totally unreasonable, but not clearly 
> marked as such.
> 
> 
>>>
>>> No, you ignored my comments.
>>>
>>> First, that isn't a trace generated by HHH emulating DDD, but by x86UTM emulating HHH, so your 
>>> claim is just a type error.
>>>
>>> Then when I look at this emulation, we see that HHH *ONLY* emulates those first 4 instructions of 
>>> HHH and no more,
>>
>> That is counter factual.
> 
> Looking closer, I may have gotten confused by the changing file by the same name
> 
> I do see the simulation continuing into HHH, but ...
> 
> One thing I do note is that the trace sees conditional jump instructions in the trace, but your 
> "rule" is that there can be no conditional instructions see in the full loop, so something is wrong.
> 
> One instruction I see is:
> Page 79, simulated the JNZ 00001335 at address 000012f8
> Why wasn't this counted as a conditional instruction in the trace?
> (That means the recursion isn't unconditional)

PO's rule is that there must be no conditional branch instructions *WITHIN DDD*.  Conditional branch 
instructions in HHH are simulated, and with suitable compilation options [I think it is the 
TRACE_USER_CODE_ONLY pre-processing symbol that needs to be undefined] those instructions will also 
be LOGGED.  Well, you're seeing the result of that on page 79 of the PDF file.

Distinction between what is LOGGED (by x86utm.exe), and what goes into the global trace table 
examined by HHH:   The former is an x86utm ("supervisor?") concept.  The latter is HHH application 
logic - HHH implements the tests for "non-halting" patterns, and only needs to capture trace entries 
needed to apply its rules.  For example, since the rules explicitly ignore trace entries from HHH, 
HHH doesn't need to capture them.  You can see those trace entries in the x86utm LOG, which is why 
the log is the way to go, when working out what's going on and why.

Just to be 100% clear for PO's benefit, when I say HHH "only needs to capture trace entries needed 
to apply its rules" I am not suggesting those rules are correct - just that from a coding 
perspective, there's no point in a program capturing data that is irrelevent for it's later 
processing.  As an example here, PO adds trace entries to his global trace table which are of no 
interest to any of his rules!  Really, he is only interested in branches, calls, and the likes, but 
he captures everything DDD does like "mov ebp,esp" or whatever which his rules all ignore...  Not an 
issue in practice because his trace captures [given other filtering] are tiny.  Might become 
important for capacity reasons if PO wanted to include HHH entries, but he doesn't.

Now, anyone thinking sensibly at this point is going to ask *WHY* does PO's rule
*exclude conditional branches within HHH* when they are obviously critical to halting?  PO will 
never explain that.  Also, as a kind of counter-balance, PO will never proof that his rule is sound, 
so I guess there's little for him to gain in trying to explain stuff like this - it's just a dead 
loss from the start.

The code in halt7.c that does the filtering is:
     ...
     // within Decide_Halting_HH...
     if (EIP > Last_Address_Of_Operating_System())  // Don't examine any OS code
     {
       PushBack(*execution_trace, (u32)*decoded, sizeof(Decoded_Line_Of_Code));
     ...

EIP is the address of the just simulated instruction.
Last_Address_Of_Operating_System() returns the address of a marker function in halt7.c, which 
effectively divides all the code in halt7.c into pre-marker and post-marker: all the 
D/DD/DDD/DDD1/... routines are post-marker (at higher addresses) so the PushBack runs, adding the 
trace entry to the global trace table.  All the H/HH/[and functions they call]... are pre-marker so 
at lower addresses, hence they are not captured in the global trace table, and so are later ignored 
by HHH logic like testing for conditional branch instructions.

You see PO's comment:  // Don't examine any OS code.   Well that's only a comment, but maybe it goes 
to PO's motivation.  [Of course, HHH code, in TM terms, is "embedded" within DDD, so /of course/ it 
needs to be inspected for conditional branches - it's the vast bulk of the code logic of DDD.  Not 
"OS code" as PO's comment might suggest.

> 
> So, mybe it is a correct partial emulation, but just ignores some of the meaning, so that 
> conditional recursion is incorrectly considered to be infinite recursion. Perhaps you just failed to 
> test you code to see that it correctly detects conditional jump instructions.
> 
> Note, examining your code, your code also VIOLATES your requirement to be a pure functikon.
> 
> First, in Init_Halts_HH you detect if you are the "root" decider by look to see it the stack is at 
> the initial prefilled value, and if so make yourself the "root" and setup a trace buffer, and record 
> that we are the "Root"
> 
> Then in Decides_Halting_HH you test that Root flag, and only the "Root" decider actually does halt 
> deciding, thus the copy of HHH that DDD calls performs a DIFFERENT set of actions to the ones that 
> the one called by main does.

You are quite right on both those points.  The result is HHH's simulation of DDD does not match the 
external running of DDD, so the simulation is a incorrect - not so much because of a failure to 
emulate a specific instruction, but because what is being simulated is not actually the proper DDD 
code /and data/.  [Specifically, the data being simulated is wrong - static variables are not in 
their correct state and so on.]

You can see the divergence in the PDF trace file if you look closely.

Mike.