Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met

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.