On 20/08/2025 22:01, olcott wrote:
On 8/20/2025 3:15 PM, Mike Terry wrote:
On 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that takes a function pointer it can
only assign or dereference, and then returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
That can't happen - (c) is performing the same calculation as (a): same code and the same input.
Sure it could. When HHH detects that it's about to recurse into itself it could just start off
a new simulation, and if it starts to run away with itself it could can /its/ simulation and
return 0.
You are describing recursive /simulation/ (or emulation). (I think...) HHH does not involve
recursive call, so what I was saying does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new simulation every time it hit DD's
HHH call, that would be quite clever. It would be easy to add static metrics to make the call
about aborting the recursion and unwinding the stack back to where it can continue simulating DD,
and nothing would be discarded as being "unreachable".
Let's see if I've fully got what you're saying. I'll use notation HHH[n] for HHH running at
nested simulation level n. So HHH[0] is outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I can say is the steps below are
little steps with no big jumps, so if you grab a pad and pen and cup of tea you can get through it
- believe that that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to spin up a new
simulation of ... DD? [must be...]
Numbering begins at 0.
My notation uses [n] to represent "simulation nesting level" n, with the convention that level 0
represents unsimulated code, i.e. called directly from main().
In all your examples, a program only performs one simulation of its own, but the program its
simulating might itself start a /nested/ simulation, and my notation was fine for that, because any
simulation was uniquely identified by its depth. In RH's suggested design AIUI, outer HHH starts
multiple simulations, and each of those is at level 1, so my notation broke down. So I chose to
label them [1b], [1c], [1d]...
Similarly, in my "play" version of x86utm code where I added in the oft-requested "simulation depth"
column in the output trace, that would break down if I coded RH's suggested HHH design: all the
[1b], [1c], [1d]... simulations would generate output trace entries showing simulation [1], because
they're all at depth 1 of simulation. [I don't plan on coding RH's suggestion though, so I won't be
"fixing" my code!]
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
HHH[0](DD) called from main() begins simulating its
DD[0] instance.
That's not my notation. DD[0] would represent DD called from main(), i.e. unsimulated.
I suppose to be completely logical, "simulation Id" might follow a tree structure like
<level 0 sequence>.<level 1 sequence>.<level 2 sequence>...
where a component sequence number n represents the n'th simulation started by its "parent"
simulator. So where my reply to RH identified simulations used the haphazard scheme I first
described above, in my all-new "logical" scheme they would be as follows:
RH Reply notation All-new "logical" notation
----------------- ------------------
HHH[0] HHH [0]
DD [1] DD [0.0]
DD [1b] DD [0.1]
DD [1c] DD [0.2]
...
And for your current HHH design, the new simulation Ids would be
HHH[0]
DD [0.0]
DD [0.0.0]
But hey, too late now :)
[..snip..]
Mike.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)