Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: 195 page execution trace of DDD correctly simulated by HH0
Date: Tue, 25 Jun 2024 21:47:38 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v5frvq$14bcm$8@i2pn2.org>
References: <v4vrfg$2793f$1@dont-email.me> <v58m12$8mmo$1@dont-email.me>
 <v59797$brmn$1@dont-email.me> <v5b7nv$qvrb$1@dont-email.me>
 <v5btf3$v0vb$4@dont-email.me> <v5chru$10816$1@i2pn2.org>
 <v5cn01$149dc$1@dont-email.me> <v5ebvr$1hs89$1@dont-email.me>
 <v5efod$1ikpr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Jun 2024 01:47:38 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1191318"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v5efod$1ikpr$1@dont-email.me>
Bytes: 5059
Lines: 107

On 6/25/24 9:12 AM, olcott wrote:
> On 6/25/2024 7:08 AM, Fred. Zwarts wrote:
>> Op 24.jun.2024 om 23:04 schreef olcott:
>>> On 6/24/2024 2:36 PM, joes wrote:
>>>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>>>> is at the addresses 2093..20a4. According to the trace no 
>>>>>>>> instruction
>>>>>>>> at the address is executed (because that address points to the last
>>>>>>>> byte of a three byte instruction.
>>>>>>>
>>>>>>> In order to make my examples I must edit the code and this 
>>>>>>> changes the
>>>>>>> addresses of some functions.
>>>>>>
>>>>>> Why do you need to make an example when you already have one in the
>>>>>> file mentioned in the subject line?
>>>>>>
>>>>> I had to make a few more examples such as HH1(DD,DD)
>>>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>>>> simulate a function DD1 that only calls HH1?
>>>>
>>>
>>> typedef uint32_t u32;
>>> u32 H(u32 P, u32 I);
>>>
>>> int P(u32 x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>>    H(P,P);
>>> }
>>>
>>> I am going to have to go through my code and standardize my names.
>>> H(P,P) was the original name. Then I had to make a one parameter
>>> version, a version that is identical to H, except P does not call
>>> it and then versions using different algorithms. People have never
>>> been able to understand the different algorithm.
>>>
>>> typedef void (*ptr)();
>>> typedef int (*ptr2)();
>>> int  HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>> int  HHH(ptr P);         // used with void DDD() that calls HHH
>>> int HHH1(ptr P);         // used with void DDD() that calls HHH
>>>
>>> *The different algorithm version has been deprecated*
>>> int  H(ptr2 , ptr2 I);  // used with int D(ptr2 P) that calls H
>>> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>>>
>>> *It is much easier for people to see the infinite recursion*
>>> *behavior pattern when they see it actually cycle through the*
>>> *same instructions twice*
>>
>> Twice is not equal to infinitely. When will you see that?
>> It is strange that you call that an infinite recursion, when H aborts 
>> after two cycles and the simulated H cannot reach its own abort 
>> operation, because it is aborted when it had only one more cycle to go.
>> None of the aborted simulations would cycle more than twice, so 
>> infinite recursion is not seen for an H that aborts the simulation of 
>> itself.
> 
> typedef void (*ptr)();
> int H0(ptr P);
> 
> void DDD()
> {
>    H0(DDD);
> }
> 
> int main()
> {
>    H0(DDD);
> }
> 
> _DDD()
> [00002172] 55               push ebp      ; housekeeping
> [00002173] 8bec             mov ebp,esp   ; housekeeping
> [00002175] 6872210000       push 00002172 ; push DDD
> [0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
> [0000217f] 83c404           add esp,+04
> [00002182] 5d               pop ebp
> [00002183] c3               ret
> Size in bytes:(0018) [00002183]
> 
> The call from DDD to H0(DDD) when DDD is correctly emulated
> by H0 cannot possibly return.

In the section thaty was correctly simulated.

It can return after that point.

Aborted simulations do NOT stop the behavior represented by the input.

> 
> Until you acknowledge this is true, this is the
> only thing that I am willing to talk to you about.
>