Re: People are still trying to get away with disagreeing with the semantics of the x86 language

On 6/29/24 2:06 PM, olcott wrote:

On 6/29/2024 12:59 PM, Richard Damon wrote:

On 6/29/24 1:17 PM, olcott wrote:

On 6/29/2024 11:45 AM, Richard Damon wrote:

On 6/29/24 12:09 PM, olcott wrote:

People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.

>
Nope, we are not disagreeing with the semantics of the x86 language, we are disagreeing with your misunderstanding of how it works.
>

>
typedef void (*ptr)();
int H0(ptr P);
>
void Infinite_Loop()
{
   HERE: goto HERE;
}
>
void Infinite_Recursion()
{
   Infinite_Recursion();
}
>
void DDD()
{
   H0(DDD);
}
>
int main()
{
   H0(Infinite_Loop);
   H0(Infinite_Recursion);
   H0(DDD);
}
>
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.

>
No the x86 language "knows" NOTHING about H0 being a x86 emulator. It is just a function that maybe happens to be a partial x86 emulator, but that is NOT a fundamental result of it being H0.
>

>
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.

>
It is construed as non-halting BECAUSE it has been shown that your H0 *WILL* terminate its PARTIAL emulation of the code it is emulating and returning.
>

>
Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.

>
Right, so H0 is REQUIRED to return, and thus if the termination analyser knows that H0 is a termination analyzer it knows that the call to H0 MUST return, and thus DDD must be a terminating program.
>
An H0 that doesn't know this, and can't figure out that H0 will return, but just keeps emulating H0 emulating its input will just fail to meet its own requirement to return.
>

>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
>
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

>
Right, and the only definition Professor Sipser uses for "Correct Simulation" is a simulation that EXACTLY REPRODUCES the behavior of the directly executed program represented by the input. Your H doesn't do that, nor correctly predicts the behavior of such a simulation of the input (since that behavior is to halt) so it can never proper avail itself of the second paragraph, so does so erroneously getting the wrong answer.
>

>
People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that
>
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

>
Except that the "N Steps of DDD correctly emulated" is NOT the definition of the "behavior" of the input DDD.
>
"inputs" Do not have "behavoir", that is a property of a program, so the input only "represents" that program, in this case the program DDD.
>

>
*According to the professor Sipser approved criteria YES IT IS*
>

>
Nope. Where dp you see that in what he says? Remember, you need to interpret the words by what he means them to say.
>
His ONLY definition of "Correct Simulation" is a simulation that exactly recreates the behavior of the program described by the input, and that in one that does not stop its simulation. So, NOT your "N Step"
>

 *N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

 Professor Sipser certainly would not be stupid enough to
disagree with the semantics of the x86 programming language.

Of course not, and the semantics of the x86 programming language say that the behavior of a piecee of code (which must be fully defined, unlike your example) is exactly what it does when run.
"Correct Emulation" of code doesn't arbitrarily stop the emulation, except to generate only a PARTIAL dec

 You are like the thief caught in the act of stealing money
from a cash register and with the stolen money still in your
hand denying that you have any stolen money in your hand.
 

Really, where is my lie?
YOU are the one that has been caught "red handed" with you numerous lies that you avoid answering about.
Where is ANY of the authorativive references for ANY of your claims?
MISSING, because you lie about them.
How does your emulator correctly emulate the call instruction when you don't provide the code it calls?
Where does the x86 language say that ANY instruction begins an "emulation" of the code provided to the instruction. (Especially when such emulation has an implicit conditionality to it that you try to ignore).
You are just proving that you whole argument is based on your own lies.