Re: Every sufficiently competent C programmer knows --- Correct Emulation Specifies Behavior

On 3/16/25 7:48 PM, olcott wrote:

On 3/16/2025 3:21 PM, joes wrote:

Am Sun, 16 Mar 2025 14:36:11 -0500 schrieb olcott:

On 3/16/2025 2:26 PM, Keith Thompson wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

On 16/03/2025 10:31, Mikko wrote:

>

False. You didn't say that HHH is a C function. In particular, the
code shown above does not say so.

>
It scarcely qualifies as C.
For example, it begins by a goto this code:
>
__asm__("lea eax, DATA1");
    __asm__("mov Aborted, eax"); __asm__("lea eax, DATA2");
    __asm__("mov execution_trace, eax");
    __asm__("mov eax, END_OF_CODE"); __asm__("mov End_Of_Code, eax");
>
which any C compiler is free to reject.
C99 introduced the asm keyword, but that's spelled asm, not __asm__,
and of course it's not a magic wand, so it can't make an inherently
unportable program work on every platform supported by C compilers.
C/370, for example, would have a fit.

>
No, C99 didn't introduce the asm keyword.  Both C90 and C99 (and all
later editions) document the "asm" keyword as a common extension, but
it's not in the list of keywords.  K&R1 (1978) mentions that some
implementations reserve "fortran" and "asm".  A conforming C compiler
must accept "asm" as an ordinary identifier.
I don't think Olcott intends HHH to be fully portable C (assuming he
knows what that means).  In any case, his claims about "Every
sufficiently competent C programmer" are ludicrous.
>

*Every sufficiently competent C programmer knows*
>
typedef void (*ptr)();
int HHH(ptr P);
>
void Infinite_Loop()
{
    HERE: goto HERE;
    return;
}
void Infinite_Recursion()
{
    Infinite_Recursion(); return;
}
void DDD()
{
    HHH(DDD);
    return;
}
int DD()
{
    int Halt_Status = HHH(DD);
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}
>
When HHH correctly emulates N steps of the above functions none of them
can possibly reach their own "return" instruction and terminate
normally.

 

The fun thing is that DDD does terminate, but HHH can't simulate it.
>

 The semantic behavioral property of THE INPUT TO HHH
is non halting as proven by DDD emulated by HHH according
to the semantics of the x86 language.
 

But since HHH doesn't actually emulate per that standard, your criteria is just nonsense.
By the criteria, when the input is given to an ACTUAL correct emulator of the x86 language, and includes the HHH that you claim got the correct answer, we see that the correct emulation will see DDD call HHH which will emulate its copy of DDD for awhile, then abort its emulation and return to DDD which will then return and reach the final state.
Thus DDD is shown by the real x86 language to be halting.

Disagreeing with the semantics of the x86 language is the
same as disagreeing with the semantics of arithmetic. The
semantics of the x86 language specifies what a correct
emulation is.

Right, and HHH doesn't do it.
You need to include the code that is actually there when you HHH was looking at DDD, and then correctly emulate that input with another CORRECT emulator that doesn't abort (like HHH1) which emulates EVERY x86 instruction.

 Disagreeing that a correct emulation of the input specifies
the behavior of this input disavows the whole notion of
a UTM.

Right, and the correct emulation, which isn't what HHH does, shows that the input will halt, at a point past the point that HHH says that it has "prved" that it can never halt.
Just proving that you are nothing but an ignorant lying idiot, as this has been explained to you many times.

 

Since HHH does see that same pattern that competent C programmers see it
correctly aborts its emulation and rejects these inputs as non
terminating.