Re: No decider is ever accountable for the behavior of the computation that itself is contained within DETAILS unless that is what the input is representing.

On 7/27/24 9:41 AM, olcott wrote:

On 7/27/2024 3:59 AM, Mad Hamish wrote:

On Fri, 26 Jul 2024 11:28:43 -0500, olcott <polcott333@gmail.com>
wrote:
>

No decider is ever accountable for the behavior of the
computation that itself is contained within.>
It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.
>

>
You might want to actually work on definitions rather than shouting
out word salad

 Which definitions do you need?
Computing the mapping from a finite string of x86 machine
language to its actual behavior is the most difficult one.
 Because HHH is an x86 emulator it merely emulates its input
including emulating itself emulating its input. That is how
the mapping is computed.

Maybe you should understand the actual meaning of your definitiion and DO it correctly.
HHH does show its emulationg itself emulating the input, it show the emulation it would do, but ignores that said emulation is CPONDITIONAL.

 Knowing the semantics of the x86 language is also required, the
best that I can do here is annotate the code. I provide the C
source code to make that easier.

Which meean that HHH needs to actually emulate the code that the call HHH points to, and can't (as you try to do) replace that with a generic idea of what that code does as an emulator.
Note: The x86 language has no concept of an instruction  causing a emulation of a piece of code, only the direct execution of the code that is in the actual stream of execution.

 typedef void (*ptr)();
int HHH(ptr P);
 void DDD()
{
   HHH(DDD);
}
 int main()
{
   DDD();
}
 *H is a termination analyzer based on an x86 emulator*
 The only two things that need to be known about HHH is that:
(a) It emulates its input in DebugStep() mode
(b) It stops emulating its input when it seen a
non-terminating behavior pattern.

Nope, You are just admitting that you are LYING that it does a "Correct x86 emulaiton" of the code, as the code can only be correctly emulated as x86 code if you have the code.
And, if you loosen your requirements to allow for just some form of equivalency emulation, the existance of condition (b) means that when you look at the emulation you need to allow for the fact that HHH might abort its emulation of the code at EVERY STEP, and thus you can not possible conclude the necessity of infinite recursion, as you have a conditional in the loop that can abort it at every steps.
Thus the only way that the code actually HAS infinite recursion is if HHH NEVER aborts, but since HHH will decide to abort, that case is not true.
So, all you are proving is you don't understand the rules of logic, you are not allowed to use the assumption of a predicate to be true, when it is actually (or even just potentially) false.

 *Here is the C source code of DDD, HHH and supporting functions*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
 *This function switches process context from HHH to DDD*
*to emulate one x86 machine language instruction of DDD*
*then switches back to HHH*
 u32  DebugStep(Registers* master_state,
                Registers* slave_state,
                Decoded_Line_Of_Code* decoded) { return 0; }
 typedef struct Decoded
{
   u32 Address;
   u32 ESP;          // Current value of ESP
   u32 TOS;          // Current value of Top of Stack
   u32 NumBytes;
   u32 Simplified_Opcode;
   u32 Decode_Target;
} Decoded_Line_Of_Code;
 Immediately before an instruction is emulated HHH
searches a scratch build std::vector<Decoded> execution_trace;
Looking for a non-halting behavior pattern.
 An x86utm operating system function provides PushBack()
void PushBack(u32 stdvector, u32 data_ptr, u32 size_in_bytes) {}
 An x86utm operating system function allocated memory
u32* Allocate(u32 size) { return 0; }