Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Why does Olcott care about simulation, anyway? --- Mikes Review
Date: Mon, 3 Jun 2024 23:57:03 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3m3af$2uv04$19@i2pn2.org>
References: <v3j20v$3gm10$2@dont-email.me>
 <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <v3jei1$3o3a7$1@dont-email.me>
 <0xqdnd8ktrnsc8D7nZ2dnZfqnPqdnZ2d@brightview.co.uk>
 <v3l002$5d3$1@dont-email.me>
 <lZadnYLpbtuB7cP7nZ2dnZfqn_udnZ2d@brightview.co.uk>
 <v3lrm2$4h2j$1@dont-email.me> <v3lsd6$2uv04$17@i2pn2.org>
 <v3ltij$8gjv$3@dont-email.me>
 <7MadnQlevYc8H8P7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
 <v3m0m0$8r46$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 4 Jun 2024 03:57:04 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3111940"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v3m0m0$8r46$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 5816
Lines: 103

On 6/3/24 11:12 PM, olcott wrote:
> On 6/3/2024 9:57 PM, Mike Terry wrote:
>> On 04/06/2024 03:18, olcott wrote:
>>> On 6/3/2024 8:59 PM, Richard Damon wrote:
>>>> On 6/3/24 9:46 PM, olcott wrote:
>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote:
> 
>>>>>> An execution trace that is produced by a program that is incorrect 
>>>>>> /proves/ nothing whatsoever. I don't need to look at your proof, 
>>>>>> as I was commenting on the value of your program output AS PROOF.
>>>>>>
>>>>>
>>>>> I provided the execution trace that HH derives
>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT*
>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT*
>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT*
>>>>
>>>> Then why did the trace not follow the call to H?
>>>>
>>>
>>> HH(DD,DD) the trace does follow the call to HH(DD,DD)
>>> and fully simulates itself simulating DD.
>>
>> Yes HH does simulate the call to HH(DD,DD) and certain instructions 
>> within HH, although because you filter those trace entries out, nobody 
>> can check that.
>>
>> The point is it simulates THE WRONG INSTRUCTIONS within HH as 
>> discussed in other posts.
>>
> 
> I conclusively proved that HH correctly simulated the instructions of
> DD and I also proved that the simulated HH also correctly simulated the
> instructions of DD by the fact that the provided execution traces by 
> both the outer and the inner nested simulations exactly matched the 
> behavior that the x86 source code of D specifies, line-by-line.

Nope, not that you have ever published, at least not by your current 
definition, as you have never to my knowledge published any trace that 
showed the x86 insturctions of HH (or H).

And the published code for H specifically does NOT simulate the 
instructions of the subroutine H.

So, where is your proof that you have done what you say.

Note, the "inner nested simulation" is NOT actually part of the 
simulaition that your outer HH is doing, but an INTERPRETATION of what 
the HH being simulated is seeing.

So, you are just proving that you don't even understand your own 
definitions because you are just a PATHOLOGICAL LIAR.

Remember, your currect definition of the ONLY THING that can be a 
"correct simulation" must follow the EXACT SEQUENCE OF INSTRUCTIONS that 
the x86 processor would execute, in the exact order, of the program, and 
thus the CALL HH instruction MUST go into HH, and thus, your "input" 
must include those instructions and thus DD is no longer a "Template" 
but must be an instance of DD as built on a given HH, and thus is a 
DIFFERENT input for each HH, and thus we can not look at a different 
HH's simulation for information about what its own simulation will do.

That, or you have lied about simulating 1 to and infinite number of 
instructions as you need to stop after only simulating 8 instructions, 
which is a lot less that infinity, as you don't have the next 
instruction to correctly simulate.


> 
> _DD()
> [00001c22] 55         push ebp
> [00001c23] 8bec       mov ebp,esp
> [00001c25] 51         push ecx
> [00001c26] 8b4508     mov eax,[ebp+08]
> [00001c29] 50         push eax        ; push DD 1c22
> [00001c2a] 8b4d08     mov ecx,[ebp+08]
> [00001c2d] 51         push ecx        ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342   ; call HH
> 
>> When HH simulates itself, the instructions simulated must be the 
>> actual instructions that "outer" HH would execute, because that's what 
>> simulation means.  What your HH does is simulate completely different 
>> instructions inside a conditional branch that asks "Am I being 
>> simulated?".  That is Simply Wrong, in a way that should be obvious 
>> without repeated explanation.  Trace output from a Simply Wrong 
>> program is not evidence for your claims.
>>
>>
>> Mike.
>>
> 
> HH(DD,DD) only gets the machine address of DD as input, that
> is its only basis. When DD calls HH then the outer HH simply
> simulates whatever this call specifies it doesn't even know
> that it is calling itself.
> 
> With your honesty and expertise we may finally get closure on this.
> 

If it doesn't know it is calling itself, then how does it know it should 
abort its simulation?

 From my memory, it used a static memory hack to detect that the 
simulated machine was itself.