Re: 197 page execution trace of DDD correctly simulated by HHH

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

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

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

On 7/1/2024 3:27 AM, Fred. Zwarts wrote:

Op 30.jun.2024 om 19:25 schreef olcott:

On 6/30/2024 3:42 AM, joes wrote:
>

No, I mean: why does the inner simulator repeat instead of aborting,
the same as the outer one does?
>

Technically it is called detecting a repeating state.

Yeah, I know. My point is: all recursive calls both enter and detect
a repeating state.
>

>
The inner ones always see one less execution trace
than the next outer one, thus could only meet their
abort criteria after they have already been aborted.
>

>
Which indicates that they were aborted too soon, showing that the emulation was incorrect.

>
Unless the outer HHH aborts its simulation after some
fixed number of correct emulations or none of the HHH
ever aborts and HHH never stops running.

>
But the outer HHH DOES abort its simulation, since you have said it did (and it either does or it doesn't).
>
That means that the simulation of DDD stops, but not the behavior of the machine that it is simulating.
>

 x86 code remains a static string and thus not a dynamic process
when it is no longer simulated. If you never heard of those two
terms before then you do not have the equivalent of a BSCS.
 

Nope. Not when you define that it is by the semantics of the x86 instruction set. At that point, its behavior becomes FULLY DEFINED even if never run or simulated.
YOU don't seem to understand the basics of programming.
You can show behavior of a program without ever actually simulating it.
In fact, "Termination Anaylsys" is based on that, as without having an actual input (since it asks about for ALL inputs) there isn't an ability to actually run or simulate the code, just analyize it for executional invariants and cases to see what it might be able to do.