Re: People are still trying to get away with disagreeing with the semantics of the x86 language

On 7/1/24 9:32 PM, olcott wrote:

On 7/1/2024 7:38 PM, Richard Damon wrote:

On 7/1/24 8:49 AM, olcott wrote:

On 7/1/2024 6:08 AM, Richard Damon wrote:

On 6/30/24 10:27 PM, olcott wrote:

On 6/30/2024 9:16 PM, Richard Damon wrote:

On 6/30/24 9:38 PM, olcott wrote:

On 6/30/2024 8:24 PM, Richard Damon wrote:

On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard Damon wrote:

>
I had to dumb this down because even the smartest
people here were overwhelmed:
>
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a cannot possibly return.

>
But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED.
>

>
I don't understand why you so stupidly lie about this.
>
_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]
>
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until aborted.
>

>
And, since the HHH that DDD calls will abort is emulation, it WILL return to DDD and it will return also.
>

>
How can stopping the emulation the first four
instructions of DDD possibly do anything besides stop?
>

>
The emulation stops, and the emulating behavor of HHH stops, but not the behavior of the input.

>
When DDD is no longer being emulated all of its behavior
stops. DDD is the input.
>

>
Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT, which isn't dependent on the emulator looking at it,

 That is a stupid lie. In input is a static string when not
emulated and only becomes a dynamic process when emulated.
*Anyone with anything like a BSCS would know that*
 

Nope, that CAN'T be the definition of the "behvior of the Input" but of the behavior of the "input processed by this machine". "Behavior" is a term used on MACHINES (so in the above case, the machine is the DECIDER, not the input). When you talk about the "behavior of the input" that needs to represent the behavior of the machine the input represents.
You just don't seem to understand the basics of the field, because you your enforce ignorance.