• Re: A state transition diagram proves ...

    From Richard Damon@21:1/5 to olcott on Thu Oct 17 21:13:24 2024
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183]
    no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+ +------------------------------------------------------+

    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2

    In fact, the correct emulation of the program will NEVER have the actual program counter of that context have the value of 00002172 again after
    it does that first step, and never be 0000217a after it executes that instruction.

    You are just showing that you arguement is based on lies, and deceit,
    and total stupidity.

    The emulation of emulation of DDD by the emulated HHH never actually
    gets to that address in this context, only in the virtual context of the machine being emulated.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 17 23:27:19 2024
    On 10/17/24 9:47 PM, olcott wrote:
    On 10/17/2024 8:13 PM, Richard Damon wrote:
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183]
    no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+
    +------------------------------------------------------+

    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2


    IS THIS OVER YOUR HEAD?
    What is the first machine address of DDD that HHH
    emulating itself emulating DDD would reach?


    Yes, HHH EMULATES the code at that address, but never gets there itself.

    You just don't seem to understand how computers work.

    Show me where the contents of the "PC" register in the virtual machine
    that the top level emulator is keeping ever get to that value.

    It is the virtual PC register that is being KEPT by that HHH that is
    being emulated that gets there.

    Your problem is you forgot to list what context each level of simulation
    in your listing was actually being done.

    Sorry, your "logic" is just full of lie, that you are too stupid to
    understand.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 18 07:17:21 2024
    On 10/17/24 11:47 PM, olcott wrote:
    On 10/17/2024 10:27 PM, Richard Damon wrote:
    On 10/17/24 9:47 PM, olcott wrote:
    On 10/17/2024 8:13 PM, Richard Damon wrote:
    On 10/17/24 7:31 PM, olcott wrote:
    _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]

    When DDD is correctly emulated by HHH according
    to the semantics of the x86 language DDD cannot
    possibly reach its own machine address [00002183]
    no matter what HHH does.

    [00002172]-->[00002173]-->[00002175]-->[0000217a]--+
    +------------------------------------------------------+

    That may not line up that same way when view




    https://en.wikipedia.org/wiki/State_diagram



    Except that 0000217a doesn't go to 00002172, but to 000015d2


    IS THIS OVER YOUR HEAD?
    What is the first machine address of DDD that HHH
    emulating itself emulating DDD would reach?


    Yes, HHH EMULATES the code at that address,

    Which HHH emulates what code at which address?


    Everyone, just once, which you should know, but ignore.

    The Emulating HHH sees those addresses at its begining and then never again.

    Then the HHH that it is emulating will see those addresses, but not the
    outer one that is doing that emulation of HHH.

    Then the HHH that the second HHH is emulating will, but neither of the
    outer 2 HHH.

    And so on.

    Which HHH do you think EVER gets back to 00002172?

    What instruction do you think that it emulates that would tell it to do so?

    It isn't the call instruction at 0000217a, as that tells it to go into HHH.

    At best the trace is:

    00002172
    00002173
    00002175
    0000217a
    conditional emulation of 00002172
    conditional emulation of 00002173
    conditional emulation of 00002175
    conditional emulation of 0000217a
    CE of CE of 00002172
    ...

    The "state" never repeats, it is alway a new state, and if HHH decides
    to abort its emulation, it also should know that every level of
    condition emulation it say will also do the same thing, and thus the
    call HHH at 0000217a will be returned from, and HHH has no idea what
    will happen after that, so it KNOWS it is ignorant of the answer.

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