Re: DDD correctly emulated by EEE --- Correct Emulation Defined --- CUT-AND-PASTE FAILED

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:27 PM, olcott wrote:

On 3/23/2025 6:55 PM, Richard Damon wrote:

On 3/23/25 6:56 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

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:

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
>

In other words an infinite set of pure x86 emulators with each one
stored at machine address 000015d2 that can be called from the above
fixed finite string of machine code IS UTTERLY BEYOND ANYTHING THAT
YOU CAN POSSIBLY IMAGINE.
I don't buy it. You are  neither that stupid nor that ignorant.
>

You can't have two different programs in one memory location at the
same time.
>

CUT-AND-PASTE FAILED
I will dumb it down for you.
Try to come up with one x86 emulator EEE at machine address 000015d2
that emulates III according to the semantics of the x86 language and
this emulated III reaches its own machine address 00002183.
>

No, STRAWMAN ERROR. You are just having a logic failure.
No, you are showing yourself to be dumb.
You can't redefine what "Correct Emulation" means without loosing the
ability to use it to answer the problem, as we can only look as
emulations instead of the original machine BECAUSE the are defined to
be the same.
The big problem with your example is that the fact that there doesn't
exist an EEE that can correct emulate this input to it final state, is
that all this proves is that this sort of emulator can never "prove"
that this sort of input is halting.
 

It only takes III calling EEE twice in sequence with no conditional
branch instructions between 00002172 and 0000217a to prove that III
specifies not haling behavior.

We also have the fact that none of the inputs you are looking at
actually match the inputs given to your deciders, because, as been
shown, the code at 000015d2 must be included in the input, or your
decider fails to be the "pure function" you agree it must be.
And if it is, it won't match the code of the decider, since EEE is not
the same program as HHH.