Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: DDD correctly emulated by HHH is Correctly rejected as
 non-halting V2 ---woefully mistaken rebuttal
Date: Fri, 26 Jul 2024 15:13:23 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <9651ca7a4eb67c679e7058b8b6f824ac693c11cf@i2pn2.org>
References: <v6rg65$32o1o$3@dont-email.me> <v73gk2$obtd$1@dont-email.me>
	<e2958e7ea04d53590c79b53bfb4bc9dff468772b@i2pn2.org>
	<v742r2$s48s$2@dont-email.me>
	<210383b2ee318f68a96d94aec314ee8b93f79b7f@i2pn2.org>
	<v75u22$19j7l$4@dont-email.me>
	<fde630817c49562bc765bdbc98e16a1582bcad53@i2pn2.org>
	<v78mda$1smtm$2@dont-email.me> <v7d5cl$2t3ja$1@dont-email.me>
	<v7ds0o$30pvh$3@dont-email.me> <v7fs29$3f4g7$1@dont-email.me>
	<v7gd17$3hlc2$2@dont-email.me> <v7ikn4$1jv5$1@dont-email.me>
	<v7j2pg$3o7r$3@dont-email.me> <v7l3di$idv1$1@dont-email.me>
	<v7lnrf$luh0$1@dont-email.me> <v7niqp$13ghd$1@dont-email.me>
	<v7obbn$17h8r$1@dont-email.me>
	<2eecnR6fa9XiWzz7nZ2dnZfqn_ednZ2d@brightview.co.uk>
	<v7tlin$2acgd$1@dont-email.me>
	<9KOcnbAqLvwnID_7nZ2dnZfqn_adnZ2d@brightview.co.uk>
	<v7us2g$2gvh6$1@dont-email.me>
	<xEydncDTQ97yhD77nZ2dnZfqnPGdnZ2d@brightview.co.uk>
	<v7v8gn$2m27k$1@dont-email.me>
	<fad91f57ff0a31257ab8ce5e2e0a47f4bd4c7bbc@i2pn2.org>
	<v809qo$2rabc$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 26 Jul 2024 15:13:23 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="435073"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5717
Lines: 75

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.