Except that an H that does report that doesn't do a complete and correct
x86 emulation of its input.
>
> Software engineers with extremely high technical competence will be able
> to verify that H correctly determines (in a finite number of steps) that
> its complete and correct x86 emulation of its input would never reach
> the "ret" instruction of P on this basis:
How? Since the resutl s WRONG and IMPOSSIBLE.
IF H(P,P) returns 0, as you later claim, then it is clear that P(P) will
call that H(P,P) and get the 0 return value and return, thus making the
non-halting answer incorrect.
>
> H knows its own machine address and on this basis:
> (a) H recognizes that P is calling H with the same arguments that H was
> called with at its machine address [0000135d].
>
> (b) There are no instructions in P that could possibly escape this
> otherwise infinitely recursive emulation.
>
> (c) H aborts its emulation of P before its call to H is invoked.
So, since H will abort its emulation, that stops the infinite loop.
You have yet to show who we need to blaim for this incorrect rule
besides you.
>
> H does do this in fully operational code that is executed in the fully
> operational x86utm operating system that is based on an very robust x86
> emulator having decades of development effort.
>
>
Just because you started with an accurate emulator, by adding code that
stops it, H no long actually is a complete and correct emulation, so
presuming it is, just creates unsound logic.
Yes, if H just does a pure emulation of its input, the P(P) will never
halt, but that H fails to decide so is incorrecct.
YOU are the one with a mental problem to think that ONE algorthm can
generate TWO DIFFERENT results when applied to the same input.
That just shows that you logic has created an inconsistent system, and
thus FALSE to provide Truth.