• Re: Anyone that claims this is not telling the truth --- V4

    From Richard Damon@21:1/5 to olcott on Mon Aug 19 19:09:03 2024
    On 8/19/24 8:34 AM, olcott wrote:
    On 8/19/2024 2:26 AM, Mikko wrote:
    On 2024-08-18 12:48:32 +0000, olcott said:

    x86utm takes the compiled Halt7.obj file of this c program
    https://github.com/plolcott/x86utm/blob/master/Halt7.c
    Thus making all of the code of HHH directly available to
    DDD and itself. HHH emulates itself emulating DDD.

    It is not an emulation of DDD if the execution differs from a
    real execution of DDD.


    *Everything that is not expressly stated below is*
    *specified as unspecified*

    void DDD()
    {
      HHH(DDD);
      return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    *It is a basic fact that DDD emulated by HHH according to*
    *the semantics of the x86 language cannot possibly stop*
    *running unless aborted* (out of memory error excluded)

    X = DDD emulated by HHH∞ according to the semantics of the x86 language
    Y = HHH∞ never aborts its emulation of DDD
    Z = DDD never stops running

    My claim boils down to this: (X ∧ Y) ↔ Z

    void EEE()
    {
      HERE: goto HERE;
    }

    HHHn correctly predicts the behavior of DDD the same
    way that HHHn correctly predicts the behavior of EEE.



    Remember, you said: Everything that is not expressly stated below is*
    specified as unspecified

    Therefore HHHn can NOT correctly emulate DDD past the call HHH
    instruction, because it doesn't HAVE the instruciton of the PROGRAM DDD
    (which is what you emulate) since it doesn't have the instruction at
    000015D2.

    The contents of the memory at 000015D2 can not be accessable to HHHn, as
    the input is described as DDD and not DDDn, so the input doesn't change
    between instances, and thus CAN'T contain that memory that changes, and
    thus is not valid to be part of the input.

    Thus we also have that HHH∞ can not exist, so both your premises just
    fail to be possible.

    Sorry, you are just repeating your error because apparently you just
    can't learn.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Tue Aug 20 11:58:40 2024
    On 2024-08-19 12:34:54 +0000, olcott said:

    On 8/19/2024 2:26 AM, Mikko wrote:
    On 2024-08-18 12:48:32 +0000, olcott said:

    x86utm takes the compiled Halt7.obj file of this c program
    https://github.com/plolcott/x86utm/blob/master/Halt7.c
    Thus making all of the code of HHH directly available to
    DDD and itself. HHH emulates itself emulating DDD.

    It is not an emulation of DDD if the execution differs from a
    real execution of DDD.


    *Everything that is not expressly stated below is*
    *specified as unspecified*

    void DDD()
    {
    HHH(DDD);
    return;
    }

    _DDD()
    [00002172] 55 push ebp ; housekeeping
    [00002173] 8bec mov ebp,esp ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404 add esp,+04
    [00002182] 5d pop ebp
    [00002183] c3 ret
    Size in bytes:(0018) [00002183]

    *It is a basic fact that DDD emulated by HHH according to*
    *the semantics of the x86 language cannot possibly stop*
    *running unless aborted* (out of memory error excluded)

    X = DDD emulated by HHH∞ according to the semantics of the x86 language
    Y = HHH∞ never aborts its emulation of DDD
    Z = DDD never stops running

    My claim boils down to this: (X ∧ Y) ↔ Z

    void EEE()
    {
    HERE: goto HERE;
    }

    HHHn correctly predicts the behavior of DDD the same
    way that HHHn correctly predicts the behavior of EEE.

    That you add "V4" in to the subject line means that your earlier
    presentations were not good enough. However, there is nothing
    above that would give any reason to expect anything better.

    The most important undefined thing above is the problem.
    There is only an attempt of a solution without a problem.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)