Re: DDD emulated by HHH diverges from DDD emulated by HHH1

On 05/06/2025 02:39, olcott wrote:

On 6/4/2025 8:28 PM, dbush wrote:

On 6/4/2025 9:08 PM, olcott wrote:

On 6/4/2025 7:41 PM, dbush wrote:

On 6/4/2025 8:32 PM, olcott wrote:

>
Show me this side-by-side trace and I will point out your mistake.

>
See below, which shows that the simulations performed by HHH and HHH1 are identical up to the point that HHH aborts, as you have agreed on the record.
>

 

>
False.  The correct trace is the one I posted, which shows all levels of emulation performed by HHH and HHH1.  See the corrections I made to your comments

 It is not supposed to do that.

Are you saying it's not supposed to include /nested/ emulations?  It is perfectly sensible to include nested emulations.

 It is supposed to show
the emulation of DDD by HHH1 and
the emulation of DDD by HHH
side-by-side to show the point where these
emulations diverge.

Just to be perfectly clear:
It is supposed to show
the emulation of DDD by *OUTER* HHH1 and
the emulation of DDD by *OUTER* HHH
side-by-side to show the point where these
emulations diverge.
That is exactly what my comparison shows.
Both these emulations include nested emulations, which are sensibly considered part of the reporting of the outer emulations.  As shown upthread, they do not diverge, but different emulators may choose to abort their emulations at different points.  (The emulations agree up to the point they are aborted.)

 DDD emulated by HHH1              DDD emulated by HHH
[00002183] push ebp               [00002183] push ebp
[00002184] mov ebp,esp            [00002184] mov ebp,esp
[00002186] push 00002183 ; DDD    [00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH    [0000218b] call 000015c3 ; HHH
 DDD emulated by HHH emulating itself
[00002183] push ebp      ;
[00002184] mov ebp,esp   ;
[00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH
 

LOL, I reckon I finally glimpsed your muddled thinking!
First of all, you are not really counting the reporting of nested emulations as being part of the outer emulation, per se.  As I explained in another post, that would be "a way of looking at the question", although not such a useful way.  [But viewed this way, it is /still/ the case that the emulations exactly match up to the point where DDD aborts the emulation.]
For some time, I've been puzzled by why, if you're discounting nested emulations, do you include the "DD emulated by HHH emulating itself" trace?!
That's your second (and fatal) mistake: you're counting it because the /immediate/ emulator is DDD, so you think it's part of "the emulation of DDD by HHH" but not "the emulation of DDD by HHH1" !!
That is REALLY DUMB, and shows a complete lack of understanding the original question!  Worse, it suggests a basic lack of understanding of what emulation is.  It's a case of scanning a sentence and just seeing a couple of keywords you recognise, then inventing your own meaning for the sentence based on that.  No "logic" involved...
If you include the behaviour of nested emulations [as is sensible, and relevant to your overall argument] then "DDD emulated by HHH emulating itself" is part of (outer) HHH1's emulation /AND/ part of (outer) HHH's emulation.
*NO DIVERSION*
If you include only the behaviour of direct emulation then "DDD emulated by HHH emulating itself"
*is NOT part of (outer) HHH1's emulation AND NOT part of (outer) HHH's emulation*.
NO DIVERSION.
What you're actually doing is neither of those options.  It is plain dumb - including or excluding based on the /name/ of the immediate (one level up) emulator.  We are discussing the results of the outer emulators, and the emulator /names/ are COMPLETELY irrelevant.  It is the /content/ of emulations we are comparing.  Nobody is interested in your useless redefinition of "divergence".
This also explains your oft repeated claim that HHH1 only emulates DDD once, whilst HHH emulates DDD twice.  You're counting the number of times during the nested emulation that DDD is emulated by an immediate emulator with the same name as the outer emulator.  Total nonsense, and completely uninteresting, I'm afraid.
I'm adding emulation to the list of abstract concepts you can't deal with.  As with other abstract concepts, you've replaced it in your mind with something concrete - specific bits of code you've written.  But that leaves you with no way to evaluate questions regarding the behaviour of that code.  This explains many things, like why you didn't know using mutable static variables was a no-no, why you put all the simulation levels in one single address space, why you conflate emulator code and (emulation) data and so on.
It also leaves the thought that nothing can possibly be achieved by posters arguing with a person who cannot understand /any/ of the basic (abstract) concepts needed to discuss his claims.  They would get the same results discussing quantum mechanics with their cats!  :)
By my own logic, this post is totally beyond your understanding, so I've wasted my time, but as ever the post is aimed at anyone else who wants to argue with you or even just to understand you, just in case they've not yet had these insights themselves...
Mike.