On 10/17/24 12:06 PM, olcott wrote:
On 10/17/2024 5:07 AM, joes wrote:
Am Wed, 16 Oct 2024 15:06:01 -0500 schrieb olcott:
On 10/16/2024 3:02 PM, joes wrote:
Am Wed, 16 Oct 2024 14:39:37 -0500 schrieb olcott:
On 10/16/2024 2:33 PM, joes wrote:
Am Wed, 16 Oct 2024 13:59:58 -0500 schrieb olcott:
On 10/16/2024 1:47 PM, joes wrote:
Am Wed, 16 Oct 2024 13:35:01 -0500 schrieb olcott:
On 10/16/2024 1:06 PM, joes wrote:
Am Wed, 16 Oct 2024 12:46:01 -0500 schrieb olcott:
On 10/16/2024 12:27 PM, joes wrote:
Am Wed, 16 Oct 2024 10:39:21 -0500 schrieb olcott:
On 10/16/2024 9:45 AM, joes wrote:
Am Wed, 16 Oct 2024 09:11:22 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 10/16/2024 9:01 AM, joes wrote:
Am Wed, 16 Oct 2024 08:31:43 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 10/16/2024 1:33 AM, joes wrote:
Terminating C functions must reach their "return" >>>>>>>>>>>>>>>>> statement.
Which DDD does.
THIS IS ALSO THE INDUSTRY STANDARD DEFINITION It is >>>>>>>>>>>>>>> stipulated that *correct_x86_emulation* means that a finite >>>>>>>>>>>>>>> string of x86 instructions is emulated according to the >>>>>>>>>>>>>>> semantics of the x86 language beginning with the first bytes >>>>>>>>>>>>>>> of this string.
You are not simulating the given program, but a version that >>>>>>>>>>>>>> differs in the abort check.
HHH is correctly emulating (not simulating) the x86 language >>>>>>>>>>>>> finite string of DDD including emulating the finite string of >>>>>>>>>>>>> itself emulating the finite string of DDD up until the point >>>>>>>>>>>>> where the emulated emulated DDD would call HHH(DDD) again. >>>>>>>>>>>> Whereupon the simulated HHH would abort, if it weren't >>>>>>>>>>>> unnecessarily aborted.
If the first HHH to meet its abort criteria does not act on this >>>>>>>>>>> criteria then none of them do.
And if the first one does, all of them do.
In theory this seems true when ignoring or failing to comprehend >>>>>>>>> key details.
In practice you programmed H impurely.
Which totally does not matter to the slightest degree when you have >>>>>>> the discipline to stay within the precisely designated scope of the >>>>>>> exact words that I am saying.
When HHH is an x86 emulation based termination analyzer then each >>>>>>> DDD *correctly_emulated_by* any HHH that it calls cannot possibly >>>>>>> return no matter what this HHH does.
Exactly, because your nested HHHs do not abort.
In other words you continue to fail to understand that unless the
first one aborts then none of them can possibly abort because they all >>>>> have the exact same code.
Then HHH should report itself as halting, when they would all abort.
They would not all abort when you pay close attention to ALL of the
details. It is utterly impossible for any of them besides the outermost
one to abort because it aborts before any of the rest of them see their
abort criteria has been met.
Only because they aren't simulated. But they are still terminating
programs. An infinite loop is still non-halting even if I never run it.
This is just over your head.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is correctly emulated by HHH according
to the semantics of the x86 language DDD cannot
possibly reach its own machine address [00002183]
no matter what HHH does.
But it is also a fact that the HHH that tries to correctly emulate that
DDD in a way that shows the final behavior of that input, doesn't ever
answer.
Since your HHH does abort its emulation, to give an answer, it doesn't
do a proper "correct emulation" by the definition that allows it to say something about the final behavior of DDD, so that fact isn't applicable.
But, the actually correct and complete emulation of that DDD (that
calls that HHH that does abort and return and thus not show what you
claim) does reach the return statement, showing that the actually
correct emulation reaches that point, and thus HHH is wrong.
It also shows that you are nothing but a stupid liar that doesn't know
what he is talking about.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)