Re: Every D correctly simulated by H never reaches its final state and halts

On 5/17/2024 11:00 AM, Mikko wrote:

On 2024-05-17 15:30:01 +0000, olcott said:
 

On 5/17/2024 2:25 AM, Fred. Zwarts wrote:

Op 17.mei.2024 om 03:15 schreef olcott:

The following is self-evidently true on the basis of the
semantics of the C programming language.
>
typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr x, ptr x);
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12   return 0;
13 }
>
In the above case a simulator is an x86 emulator that correctly
emulates at least one of the x86 instructions of D in the order
specified by the x86 instructions of D.
>
This may include correctly emulating the x86 instructions of H
in the order specified by the x86 instructions of H thus calling
H(D,D) in recursive simulation.
>
Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach its own line 06 and halt.
>
*This is a simple software engineering verified fact*
>

>
Note that olcott defines 'verified fact' as 'proven fact', but he is unable to show the proof. So, it must be read as 'my belief'.

>
It is self-evidently true to anyone having sufficient knowledge
of the semantics of the C programming language.

 No, it isn't, because the C code of H is not shown.

*I DON'T KNOW WHY I MUST REPEAT THIS HUNDREDS OF TIMES*
The C code that <is> shown provides the template for the
infinite set of every D correctly simulated by H.

The actual
implementation of H as decribed in some earlier messages is
not fully encoded in standard C, so in order to understand the
behaviour of D one needs to know and understand something that
is not given as a C code and therefore not understandable from
mere knowing the C language definition.
 

*SUFFICIENTLY KNOWING THE SEMANTICS OF C*
*SUFFICIENTLY KNOWING THE SEMANTICS OF C*
*SUFFICIENTLY KNOWING THE SEMANTICS OF C*
I could cast uint32_t to and from the various function pointer
types yet this is more difficult for people to understand.
I got complaints about this.
It is simpler and easier to do this: typedef int (*ptr)();
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer