Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2 ---woefully mistaken rebuttal

Am Fri, 26 Jul 2024 08:54:32 -0500 schrieb olcott:

On 7/26/2024 3:50 AM, joes wrote:

Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:

On 7/25/2024 10:35 PM, Mike Terry wrote:

On 26/07/2024 01:53, olcott wrote:

On 7/25/2024 4:03 PM, Mike Terry wrote:

On 25/07/2024 14:56, olcott wrote:

On 7/24/2024 10:29 PM, Mike Terry wrote:

On 23/07/2024 14:31, olcott wrote:

On 7/23/2024 1:32 AM, 0 wrote:

On 2024-07-22 13:46:21 +0000, olcott said:

On 7/22/2024 2:57 AM, Mikko wrote:

On 2024-07-21 13:34:40 +0000, olcott said:

On 7/21/2024 4:34 AM, Mikko wrote:

On 2024-07-20 13:11:03 +0000, olcott said:

On 7/20/2024 3:21 AM, Mikko wrote:

On 2024-07-19 14:08:24 +0000, olcott said:

In this case we have two x86utm machines that are identical
except that DDD calls HHH and DDD does not call HHH1.

I don't see how the outside use of a function can influence it.

Then we know that HHH can see the the first four instructions of DDD
have no conditional code that could prevent them from endlessly
repeating.

True, but HHH does have a conditional abort. It should be coded to
recognise that, because one knows that at compile time already.

The relative addressing is to be expected as a difference, and is
fine provided the actual target is the same. [Which it seems to
be...]
The whole thing with the slave instances might well be where the bug
lies!  That would be slightly funny, as I pointed out that problem on
some completely unrelated post, and this could be a follow-on issue
where it has caused observable misbehavior in the code.  (Needs a bit
more investigation...)

There never is any actual bug with the simulation.

I bet my nonexistent soul that there are bugs left in libx86. Apart
from that, your use of the library may be buggy.

That is irrelevant. We can see by the execution trace of DDD emulated by
HHH that this emulation does precisely match the semantics of the first
four x86 machine language instructions of DDD.

But not what comes afterwards, and HHH makes the incorrect assumption
that another instance of itself wouldn't abort.

b)  If the two behaviours HHH/HHH1 are indeed different, WHAT
precisely is the coding
      difference that accounts for that different behaviour?
      (Like, with your H/H1 the difference was that H used H's
      address as part of its algorithm, while H1 used H1's
      address.)

DDD calls HHH(DDD) in recursive simulation and does not call
HHH1(DDD)
in recursive simulation.

You may have said it 500 times, but it doesn't answer my question!

The problem is that the code itself has already answered this question
500 times in three years and people just ignore it.
When DDD emulated by HHH calls HHH(DDD) this call cannot possibly
return. When DDD emulated by HHH1 calls HHH(DDD) this call DOES
return.

How can the same code return when called once and not another time?

Look, here is a rough sketch of the two traces side by side just done
by hand:
So HHH/HHH1 behaviour is different, but shouldn't be if HHH1 is a
correct copy of HHH.

And by your same reasoning 2 + 3 shouldn't = 5.

No, 2+3 = 3+2. You have two copies of the same function that behave
differently. How is that possible?

Try to find one x86 instruction that is emulated incorrectly.

Can you please point us to where they diverge?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.