• Re: D simulated by H where H is a C interpreter --- What is up with Mik

    From olcott@3:633/10 to All on Sun Nov 9 15:59:51 2025
    Subject: Re: D simulated by H where H is a C interpreter --- What is up with Mike ???

    On 11/8/2025 10:44 PM, Mike Terry wrote:
    On 09/11/2025 02:08, olcott wrote:
    On 11/8/2025 6:30 PM, Mike Terry wrote:
    On 08/11/2025 20:54, olcott wrote:

    I see you've not changed your behaviour regarding insulting posters by
    name in the titles of your posts.ÿ Several people have informed you that that is considered bad etiquette for usenet posts.

    Just for the lols, I've changed the title to insult you! Ho ho ho, what
    a laugh.


    Regarding your intensions to continue with your C interpretter
    devolopment:ÿ that's great, really. Your time is your own, even if
    others question whether you might be wasting it.

    I suppose time will tell whether it fails to achieve what you expect it
    to achieve, as I warned. [..but it seems from your reply (snipped) time
    will only tell us and not you; that's ok too..]


    Mike.


    *Updated words*
    Simulating termination analyzer H simulates
    N statements of D according to the semantics of
    the C programming language. H does this until it
    matches a correct non-halting behavior pattern.
    This pattern conclusively proves that the simulated
    D cannot possibly reach its own simulated "return"
    statement final halt state for any value of N.

    Then H aborts its simulation and returns 0 on the
    basis that that its input D specifies a non-halting
    sequence of instructions.

    This is empirically proven by a C interpreter.
    (Detailed design provided below)

    int H(char* P);

    int D()
    {
    int Halt_Status = H(D);
    if (Halt_Status)
    HERE: goto HERE;
    return Halt_Status;
    }

    The above is assumed in in test.c

    simulate.exe implements a C interpreter.

    Command line invocation: simulate test.c

    When this interpreter sees the call to H(D) it
    calls itself with the text body of D. I intend
    to make this generic for any named function.

    The above proves that N instructions of D simulated
    by H according to the semantics of the C programming
    language cannot possibly reach its own "return"
    statement final halt state.

    It is estimated that the adaptation of an existing
    C interpreter should take about one full time week.
    I already found one that can call itself recursively.

    The tricky part that might require YACC and LEX is
    parsing the input file to recognize instances of H
    that must be called with text strings of function bodies.

    --
    Copyright 2025 Olcott

    "Talent hits a target no one else can hit;
    Genius hits a target no one else can see."
    Arthur Schopenhauer

    --- PyGate Linux v1.5
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Tue Nov 11 00:44:57 2025
    Subject: Re: D simulated by H where H is a C interpreter --- What is up with Mike ???

    On 11/9/2025 1:59 PM, olcott wrote:
    On 11/8/2025 10:44 PM, Mike Terry wrote:
    On 09/11/2025 02:08, olcott wrote:
    On 11/8/2025 6:30 PM, Mike Terry wrote:
    On 08/11/2025 20:54, olcott wrote:

    I see you've not changed your behaviour regarding insulting posters by
    name in the titles of your posts.ÿ Several people have informed you
    that that is considered bad etiquette for usenet posts.

    Just for the lols, I've changed the title to insult you! Ho ho ho,
    what a laugh.


    Regarding your intensions to continue with your C interpretter
    devolopment:ÿ that's great, really. Your time is your own, even if
    others question whether you might be wasting it.

    I suppose time will tell whether it fails to achieve what you expect
    it to achieve, as I warned. [..but it seems from your reply (snipped)
    time will only tell us and not you; that's ok too..]


    Mike.


    *Updated words*
    ÿ Simulating termination analyzer H simulates
    ÿ N statements of D according to the semantics of
    ÿ the C programming language. H does this until it
    ÿ matches a correct non-halting behavior pattern.
    ÿ This pattern conclusively proves that the simulated
    ÿ D cannot possibly reach its own simulated "return"
    ÿ statement final halt state for any value of N.

    ÿ Then H aborts its simulation and returns 0 on the
    ÿ basis that that its input D specifies a non-halting
    ÿ sequence of instructions.

    This is empirically proven by a C interpreter.
    (Detailed design provided below)

    int H(char* P);

    int D()
    {
    ÿ int Halt_Status = H(D);
    ÿ if (Halt_Status)
    ÿÿÿ HERE: goto HERE;
    ÿ return Halt_Status;
    }

    The above is assumed in in test.c

    simulate.exe implements a C interpreter.

    Command line invocation: simulate test.c

    When this interpreter sees the call to H(D) it
    calls itself with the text body of D. I intend
    to make this generic for any named function.

    The above proves that N instructions of D simulated
    by H according to the semantics of the C programming
    language cannot possibly reach its own "return"
    statement final halt state.

    It is estimated that the adaptation of an existing
    C interpreter should take about one full time week.
    I already found one that can call itself recursively.

    The tricky part that might require YACC and LEX is
    parsing the input file to recognize instances of H
    that must be called with text strings of function bodies.


    Why even have H at all? Look at the source code itself, do some static analysis on it. H is pointless here? D can be:
    ______________________
    int D(int status)
    {
    if (status)
    {
    for (;;)
    {
    // lol...
    }
    }

    return status;
    }
    ______________________

    right?

    --- PyGate Linux v1.5
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Tue Nov 11 00:47:44 2025
    Subject: Re: D simulated by H where H is a C interpreter --- What is up with Mike ???

    On 11/11/2025 12:44 AM, Chris M. Thomasson wrote:
    On 11/9/2025 1:59 PM, olcott wrote:
    On 11/8/2025 10:44 PM, Mike Terry wrote:
    On 09/11/2025 02:08, olcott wrote:
    On 11/8/2025 6:30 PM, Mike Terry wrote:
    On 08/11/2025 20:54, olcott wrote:

    I see you've not changed your behaviour regarding insulting posters
    by name in the titles of your posts.ÿ Several people have informed
    you that that is considered bad etiquette for usenet posts.

    Just for the lols, I've changed the title to insult you! Ho ho ho,
    what a laugh.


    Regarding your intensions to continue with your C interpretter
    devolopment:ÿ that's great, really. Your time is your own, even if
    others question whether you might be wasting it.

    I suppose time will tell whether it fails to achieve what you expect
    it to achieve, as I warned. [..but it seems from your reply (snipped)
    time will only tell us and not you; that's ok too..]


    Mike.


    *Updated words*
    ÿÿ Simulating termination analyzer H simulates
    ÿÿ N statements of D according to the semantics of
    ÿÿ the C programming language. H does this until it
    ÿÿ matches a correct non-halting behavior pattern.
    ÿÿ This pattern conclusively proves that the simulated
    ÿÿ D cannot possibly reach its own simulated "return"
    ÿÿ statement final halt state for any value of N.

    ÿÿ Then H aborts its simulation and returns 0 on the
    ÿÿ basis that that its input D specifies a non-halting
    ÿÿ sequence of instructions.

    This is empirically proven by a C interpreter.
    (Detailed design provided below)

    int H(char* P);

    int D()
    {
    ÿÿ int Halt_Status = H(D);
    ÿÿ if (Halt_Status)
    ÿÿÿÿ HERE: goto HERE;
    ÿÿ return Halt_Status;
    }

    The above is assumed in in test.c

    simulate.exe implements a C interpreter.

    Command line invocation: simulate test.c

    When this interpreter sees the call to H(D) it
    calls itself with the text body of D. I intend
    to make this generic for any named function.

    The above proves that N instructions of D simulated
    by H according to the semantics of the C programming
    language cannot possibly reach its own "return"
    statement final halt state.

    It is estimated that the adaptation of an existing
    C interpreter should take about one full time week.
    I already found one that can call itself recursively.

    The tricky part that might require YACC and LEX is
    parsing the input file to recognize instances of H
    that must be called with text strings of function bodies.


    Why even have H at all? Look at the source code itself, do some static analysis on it. H is pointless here? D can be:

    You can inject something like this:

    ______________________
    int D(int status)
    {
    if (status)
    {
    for (;;)
    {
    // lol...

    ct_yield(...);

    }
    }

    return status;
    }
    ______________________



    --- PyGate Linux v1.5
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)