Re: DDD emulated by HHH --- (does not refer to prior posts)

Op 29.aug.2024 om 19:36 schreef olcott:

On 8/29/2024 12:22 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 16:07 schreef olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:
>

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:
>

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.
>
void DDD()
{
   HHH(DDD);
   return;
}
>
_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 we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.
>
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.
>

>
>
Yes, we see. In fact DDD is not needed at all.

>
A straw man fallacy (sometimes written as strawman) is the informal fallacy of refuting an argument different from the one actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

>
You should also point a link to the equivocation fallacy. You use it
more often than straw man.

>
Isomorphism is not equivocation

>
The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.
>
Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.
>

>
void EEE()
{
   HERE: goto HERE;
   return;
}
>
HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.
>
void DDD()
{
   HHH(DDD);
   return;
}
>
HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

Which is incorrect, because HHH is not allowed to change the input. The simulating HHH may abort, but it may not ignore the fact that the input (the simulated HHH) is coded to abort when it sees the 'special condition'. Otherwise it would decide about a non-input, which is not allowed.
>

 *I told you this too many times so you must be a liar*

You told so many times incorrect claims.

No DDD ever reaches its "return" instruction no matter
what-the-Hell that HHH does,

Proving that the simulation is incorrect.
No matter what HHH does, it cannot possibly simulate itself up to the end.
        int main() {
          return HHH(main);
        }
HHH halts, but it decides that it does not halt. That is the problem. DDD only calls HHH, so, the problem is not DDD, but HHH.
You are such a slow learner. I told you this so many times, but it seems your memory is very short.

thus DDD CANNOT POSSIBLY HALT.
 

DDD does halt, if allowed to do so. But the simulating HHH does not allow it, because it aborts one cycle before the simulated HHH would detect the 'special condition' and return to DDD. By stopping the simulation before it could halt, you cannot prove that "DDD CANNOT POSSIBLY HALT". In fact DDD halts. The finite string has only one behaviour according to the semantics of the x86 language and both the direct execution and the simulation by HHH1 show what the behaviour of the program described by this finite string is: a halting program. Therefore, anyone who claims that this finite string describes a non-halting program according to the semantics of the x86 language, is very stupid, or is lying.