Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: DDD correctly emulated by EEE --- Correct Emulation Defined
Date: Sun, 23 Mar 2025 17:46:26 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <620b2d2b4fcea2b169555e3ba9ba426f00c908ef@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <vrmirg$5bpl$1@dont-email.me>
 <ca0a3e4701bc62fa38f1138064feff7628ff5b48@i2pn2.org>
 <vrmtrn$cvat$7@dont-email.me>
 <678373dd34320b3c8250f1e75c849a16316d8ae8@i2pn2.org>
 <vro0rb$1c9ia$2@dont-email.me>
 <bddeb5144881ad5d343c0dcde12715352028487a@i2pn2.org>
 <vrpguc$2qbhf$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 23 Mar 2025 21:46:26 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1466043"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <vrpguc$2qbhf$3@dont-email.me>
Bytes: 5076
Lines: 95

On 3/23/25 1:38 PM, olcott wrote:
> On 3/23/2025 6:08 AM, Richard Damon wrote:
>> On 3/22/25 11:57 PM, olcott wrote:
>>> On 3/22/2025 9:53 PM, Richard Damon wrote:
>>>> On 3/22/25 2:00 PM, olcott wrote:
>>>>> On 3/22/2025 12:34 PM, Richard Damon wrote:
>>>>>> On 3/22/25 10:52 AM, olcott wrote:
>>>>>>> _DD()
>>>>>>> [00002133] 55         push ebp      ; housekeeping
>>>>>>> [00002134] 8bec       mov ebp,esp   ; housekeeping
>>>>>>> [00002136] 51         push ecx      ; make space for local
>>>>>>> [00002137] 6833210000 push 00002133 ; push DD
>>>>>>> [0000213c] e882f4ffff call 000015c3 ; call EEE(DD)
>>>>>>> [00002141] 83c404     add esp,+04
>>>>>>> [00002144] 8945fc     mov [ebp-04],eax
>>>>>>> [00002147] 837dfc00   cmp dword [ebp-04],+00
>>>>>>> [0000214b] 7402       jz 0000214f
>>>>>>> [0000214d] ebfe       jmp 0000214d
>>>>>>> [0000214f] 8b45fc     mov eax,[ebp-04]
>>>>>>> [00002152] 8be5       mov esp,ebp
>>>>>>> [00002154] 5d         pop ebp
>>>>>>> [00002155] c3         ret
>>>>>>> Size in bytes:(0035) [00002155]
>>>>>>>
>>>>>>> When finite integer N instructions of the above x86
>>>>>>> machine language DD are emulated by each x86 emulator
>>>>>>> EEE[N] at machine address [000015c3] according to the
>>>>>>> semantics of the x86 language no DD ever reaches its own
>>>>>>> "ret" instruction at machine address [00002155] and
>>>>>>> terminates normally.
>>>>>>>
>>>>>>
>>>>>> Your can't emulate the above code for N > 4, as you get into 
>>>>>> undefine memory.
>>>>>>
>>>>>
>>>>> I have already addressed this objection dozens of times.
>>>>>
>>>>
>>>> No you haven't. You have given several different LIES about it.
>>>>
>>>> As I have pointed out, if you don't include Halt7.c as part of the 
>>>> definition, then you can't do it as you are looking at undefined 
>>>> memory.
>>>>
>>>
>>> Your lack of technical competence is showing.
>>> (1) We are talking about a hypothetical infinite
>>> set of pure x86 emulators that have no decider code.
>>>
>>> (2) The memory space of x86 machine code is not
>>> in the C source file, it is in the object file.
>>>
>>
>> Then your "input" isn't the C source files, but the memory, and ALL of 
>> it, and thus in your (1), each member of the set got a different input 
>> (as reference memory changed) and none of those apply to your case 
>> with HHH.
>>
>> You just continue to prove that you don't understand the meaning of 
>> the terms you are using, or you are intentionally hiding your 
>> fradulant change of meaning of those terms.
>>
> 
> Command line arguments:
> x86utm Halt7.obj > Halt7out.txt
> 
> All of the x86 functions remain at their same fixed
> offset from the beginning of Halt7.obj

So?

You still need to make the decision, is Halt7.c / Halt7.obj part of the 
INPUT to the decider, and thus either you can't change the code in it, 
or you need to consider each version a different input, or

do you consider it NOT part of the input, and thus you criteria BREAKS 
when you look at "data" that isn't part of the input.

Of course you get strange results when you allow your decider to be 
influenced by things that aren't part of the official question, and if 
you are saying that is allowed, your system becomes thus pretty much 
worthless, and any decider could use data not part of its input and thus 
claim wrong answers to be correct.

Sorry, but until you show that indeterminate program are a worthwhile 
thing to consider, you are just proving your whole system is just a fraud.

> 
>> Your logic is just build on self-contradictions and thus is unsound.
>>
>> Sorry, you are just proving your utter stupidity and ignorance of what 
>> you speak about.
> 
>