Deutsch   English   Français   Italiano  
<XpCdnbOhAMLeVOH7nZ2dnZfqn_GdnZ2d@brightview.co.uk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!Xl.tags.giganews.com!local-2.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Jun 2024 02:06:59 +0000
Subject: Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved
 criteria is met
Newsgroups: comp.theory,sci.logic
References: <v45tec$4q15$1@dont-email.me> <v50dtp$2e5ij$1@dont-email.me>
 <v51f4t$2k8ar$1@dont-email.me> <v51ge4$2kbbe$2@dont-email.me>
 <v539bk$329sv$1@dont-email.me> <v53upb$35vak$6@dont-email.me>
 <v575pl$3sg5p$1@dont-email.me> <v5767s$3soh6$1@dont-email.me>
 <v5e28t$11urb$5@i2pn2.org> <v5eg03$1ikpr$2@dont-email.me>
 <v5eho7$24l4$1@news.muc.de> <87jzidm83f.fsf@bsb.me.uk>
 <v5el8c$24l4$4@news.muc.de> <v5evoi$1lgoi$1@dont-email.me>
 <v5frvn$14bcm$6@i2pn2.org> <v5ft1p$1uc3o$2@dont-email.me>
 <v5fu24$14bcn$2@i2pn2.org> <v5fuf7$1up2o$1@dont-email.me>
 <v5fvvk$14bcn$4@i2pn2.org> <v5g1ue$1v8bm$2@dont-email.me>
 <v5g29u$14bcm$11@i2pn2.org> <v5g2nd$1v8bm$4@dont-email.me>
 <v5gsfv$15l89$2@i2pn2.org> <v5h5sd$24jbd$10@dont-email.me>
 <v5i8v9$17ej1$2@i2pn2.org> <v5i998$2cko8$1@dont-email.me>
 <v5i9ot$17ej0$3@i2pn2.org> <v5ib7n$2cko8$4@dont-email.me>
 <v5ichc$17ej1$8@i2pn2.org>
 <5nSdnSkMN76jIOH7nZ2dnZfqnPidnZ2d@brightview.co.uk>
 <yumdnWJaTZk7XeH7nZ2dnZfqn_WdnZ2d@brightview.co.uk>
 <v5igku$17ej0$5@i2pn2.org>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Thu, 27 Jun 2024 03:06:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <v5igku$17ej0$5@i2pn2.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <XpCdnbOhAMLeVOH7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
Lines: 82
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9x1Mr4tEWV8xGI2nPrzP5x1YD82amhEn04n8YRH4GIqKl6SyR8sVtvS5FDBX+q6+rSwRiJsTVKAVEzQ!9re+XcWqM6SgtgMGwRwr+WZ+xnqdqiCBH6zYVHNpHZVmBEewIGOAnP2XHHmOYpLJfrKGDteT68+3!Ghlj4qfOg5mMNT/5K0XUgtEFLb1b
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 5295

On 27/06/2024 02:52, Richard Damon wrote:
> On 6/26/24 9:30 PM, Mike Terry wrote:
>> On 27/06/2024 02:15, Mike Terry wrote:
>>> On 27/06/2024 01:42, Richard Damon wrote:
>>>> On 6/26/24 8:20 PM, olcott wrote:
>>>>> On 6/26/2024 6:55 PM, Richard Damon wrote:
>>>>>> On 6/26/24 7:46 PM, olcott wrote:
>>>>>>> On 6/26/2024 6:41 PM, Richard Damon wrote:
>>>>>>>> On 6/26/24 9:42 AM, olcott wrote:
>>>>>>>>> On 6/26/2024 6:02 AM, Richard Damon wrote:
>>>>>>>>>> On 6/25/24 11:42 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> That is not the way that it actually works.
>>>>>>>>>>> That the the way that lies are defined.
>>>>>>>>>>
>>>>>>>>>> Source for you claim?
>>>>>>>>>>
>>>>>>>>>> Where is you finite set of steps from the truthmakers of the system to that claim?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [00002172] 55�������������� push ebp����� ; housekeeping
>>>>>>>>> [00002173] 8bec������������ mov ebp,esp�� ; housekeeping
>>>>>>>>> [00002175] 6872210000������ push 00002172 ; push DDD
>>>>>>>>> [0000217a] e853f4ffff������ call 000015d2 ; call H0(DDD)
>>>>>>>>> [0000217f] 83c404���������� add esp,+04
>>>>>>>>> [00002182] 5d�������������� pop ebp
>>>>>>>>> [00002183] c3�������������� ret
>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>
>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated
>>>>>>>>> by H0 cannot possibly return.
>>>>>>>>
>>>>>>>> Sure it can. I have shown an H0 that does so.
>>>>>>>>
>>>>>>>
>>>>>>> I already told you that example does not count.
>>>>>>>
>>>>>>> I can't keep repeating those details or others
>>>>>>> that so far have no idea what an x86 emulator is
>>>>>>> will be baffled beyond all hope of comprehension.
>>>>>>>
>>>>>>
>>>>>> WHy not?
>>>>>>
>>>>>
>>>>> We have already been over that you know that you cheated.
>>>>>
>>>>
>>>> Nope, since you didn't put in the rule, and if you had it would have shown that you lied, as if 
>>>> H0 is a pure function then the call to H0 emulated by H0 needs to have the same behaivor as the 
>>>> direct call to H0 by main.
>>>
>>> Incidentally, the nonconformance you're referring to is shown explicitly in the "195 page trace" 
>>> that PO linked to.� [I.e. the simulated H does not correctly track the code path of the outer H.]
>>
>> I suppose I should have made clear, that's not simply due to the simulated H being aborted.� There 
>> is an instruction in H:�� [actually, in Init_Halts_HH()]
>>
>> [000012e4] 753b jnz 00001321
>>
>> and in outer H control proceeds to 000012e6� [i.e. branch not taken],
>> whilein simulated H control proceeds to 00001321� [i.e. branch taken]
>>
>>
>> Mike.
>>
> 
> Would need to look closer at the code, but I bet that the simulated machine is looking into the 
> trace buffer to see if it is simulated or not.

Has PO published the C code for the trace?  Anyhow, given that its in Init_Halts_HH(), I expect its 
a global area being initialised - probably the global trace table.

> 
> In effect, it is misusing static memory just like he says isn't allowed.

Right.


Mike.