XPost: comp.theory, comp.lang.c++, comp.lang.c
From: polcott333@gmail.com
On 8/20/2025 8:24 PM, Mike Terry wrote:
> 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:
>>>>
>>>>
>>>>
>>>>>> 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().
>
I am changing my notation to be consistent with yours.
*These details are crucial for you and Kaz to see*
*Numbering begins at 0 for direct execution*
DD() is executed in main
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
DD[0] is invoked and calls HHH[0] that creates a
separate DD[1] process context with its own set of
16 virtual registers and virtual stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same
DD[1] process context.
When HHH[1] begins simulating its own DD[2] it must
create a separate DD[2] process context with its own
set of 16 virtual registers and virtual stack...
on and on until OOM error (proving non-halting) when
we eliminate the u32* execution_trace data.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
