On Friday, July 1, 2022 at 10:53:13 AM UTC-7, olcott wrote:
> On 7/1/2022 12:41 PM, dklei...@gmail.com wrote:
> > On Friday, July 1, 2022 at 9:52:10 AM UTC-7, olcott wrote:
> >>
> >> Anyone that disagrees with this is disagreeing with the semantics of the
> >> x86 language.
> >>
> >> INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
> >> https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
> >> void P(u32 x)
> >
> > How is this compatible with requiring the Visual C compiler?
> The above precisely documents that machine architecture and its machine
> code which forms a bijection to Intel 80386 assembly language.

I am not familiar with Visual C but I cannot imagine Microsoft not
targetting more modern processors than the 386. If one looks at
the Visual C compiler output one might well encounter instructions
not executed by the 386. But the output of the compiler itself is
surely not op-code. Unless told otherwise I assume the compiler
output is in an intermediate language which is then further translated
into actual op-codes. If there is any optimization in Visual C I would
expect it to occur in this final step. Is there any optimization in
your use of Visual C?

On 7/1/2022 4:26 PM, dklei...@gmail.com wrote:
> On Friday, July 1, 2022 at 10:53:13 AM UTC-7, olcott wrote:
>> On 7/1/2022 12:41 PM, dklei...@gmail.com wrote:
>>> On Friday, July 1, 2022 at 9:52:10 AM UTC-7, olcott wrote:
>>>>
>>>> Anyone that disagrees with this is disagreeing with the semantics of the
>>>> x86 language.
>>>>
>>>> INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
>>>> https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
>>>> void P(u32 x)
>>>
>>> How is this compatible with requiring the Visual C compiler?
>> The above precisely documents that machine architecture and its machine
>> code which forms a bijection to Intel 80386 assembly language.
>
> I am not familiar with Visual C but I cannot imagine Microsoft not
> targetting more modern processors than the 386. If one looks at

The x86 emulator can do 32-bit code at best. The newest compilers will
generate 32-bit code when required. x86 means 32-bit code. 80386
was the first architecture with the flat 32-bit address space.

> the Visual C compiler output one might well encounter instructions
> not executed by the 386. But the output of the compiler itself is
> surely not op-code. Unless told otherwise I assume the compiler
> output is in an intermediate language which is then further translated
> into actual op-codes.

Not at all it is all binary machine code.

> If there is any optimization in Visual C I would
> expect it to occur in this final step. Is there any optimization in
> your use of Visual C?

Optimizing the code makes it harder to read:
cl /GS- /FAcu /FaHalt7.lst /c /arch:IA32 Halt7.c

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/1/22 11:37 AM, olcott wrote:
> On 7/1/2022 10:18 AM, Mikko wrote:
>> On 2022-07-01 12:38:34 +0000, olcott said:
>>
>>> On 7/1/2022 4:29 AM, Mikko wrote:
>>
>>>> On 2022-06-30 14:53:13 +0000, olcott said:
>>
>>>>> A function only halts when it reaches its "ret" instruction.
>>
>>> It is only pure C functions (no library calls) translated into COFF
>>> object file machine code by the Visual Studio C compiler that can be
>>> used as input to x86utm operating system's halt decider.
>>
>> You didn't say that only pure C functions (no library calls) translated
>> into COFF object file machine code by the Visual Studio C compiler halt.
>>
>> Mikko
>>
>
> The above is the domain of the halt decider H.
>

So, is "H" a library function and thus P not in the domain of H?

Or, does P need its own copy of H (and then does H meet that requirement?)

If H doesn't meet the requirement, you just defined your system to not
be Turing Complete.

On 7/1/22 12:52 PM, olcott wrote:
> On 7/1/2022 11:39 AM, Paul N wrote:
>> On Thursday, June 30, 2022 at 5:10:30 PM UTC+1, olcott wrote:
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Exactly. H(T, X) must tell us whether T(X) actually halts or not. In
>> particular, H(P, P) must tell us whether P(P) actually halts or not.
>>
>
> *This is necessarily true thus impossibly false*
> Every simulating halt decider that correctly simulates its input until
> it correctly determines that this simulated input would never reach its
> final state, correctly rejects this input as non-halting.
>
> It is provably not the case when H(P,P) correctly emulates its input
> with an x86 emulator that the behavior of the emulated input is the same
> as the behavior of the directly executed P(P).

Then what x86 instruction differed in its execution between the two?

It appears the difference is because H doesn't actually do an x86
emulation of the code following the call H instruction, and thus FAILS
to preform a correct x86 emulation.

>
> Anyone that disagrees with this is disagreeing with the semantics of the
> x86 language.
>
> INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
> https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000011f0](01)  55              push ebp
> [000011f1](02)  8bec            mov ebp,esp
> [000011f3](03)  8b4508          mov eax,[ebp+08]
> [000011f6](01)  50              push eax
> [000011f7](03)  8b4d08          mov ecx,[ebp+08]
> [000011fa](01)  51              push ecx
> [000011fb](05)  e820feffff      call 00001020
> [00001200](03)  83c408          add esp,+08
> [00001203](02)  85c0            test eax,eax
> [00001205](02)  7402            jz 00001209
> [00001207](02)  ebfe            jmp 00001207
> [00001209](01)  5d              pop ebp
> [0000120a](01)  c3              ret
> Size in bytes:(0027) [0000120a]
>
> _main()
> [00001210](01)  55              push ebp
> [00001211](02)  8bec            mov ebp,esp
> [00001213](05)  68f0110000      push 000011f0
> [00001218](05)  e8d3ffffff      call 000011f0
> [0000121d](03)  83c404          add esp,+04
> [00001220](02)  33c0            xor eax,eax
> [00001222](01)  5d              pop ebp
> [00001223](01)  c3              ret
> Size in bytes:(0020) [00001223]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001210][00101fba][00000000] 55         push ebp
> [00001211][00101fba][00000000] 8bec       mov ebp,esp
> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> [000011f0][00101fae][00101fba] 55         push ebp      // enter executed P
> [000011f1][00101fae][00101fba] 8bec       mov ebp,esp
> [000011f3][00101fae][00101fba] 8b4508     mov eax,[ebp+08]
> [000011f6][00101faa][000011f0] 50         push eax      // push P
> [000011f7][00101faa][000011f0] 8b4d08     mov ecx,[ebp+08]
> [000011fa][00101fa6][000011f0] 51         push ecx      // push P
> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>
> Begin Simulation   Execution Trace Stored at:21206e
> Address_of_H:1020
> [000011f0][0021205a][0021205e] 55         push ebp      // enter emulated P
> [000011f1][0021205a][0021205e] 8bec       mov ebp,esp
> [000011f3][0021205a][0021205e] 8b4508     mov eax,[ebp+08]
> [000011f6][00212056][000011f0] 50         push eax      // push P
> [000011f7][00212056][000011f0] 8b4d08     mov ecx,[ebp+08]
> [000011fa][00212052][000011f0] 51         push ecx      // push P
> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.

But the x86 instructions in H that P calls are part of the x86 code of
P. Read the manual, a call instruction doesn't create a new thing that
isn't part of the original.

You (b) is invalid logic.

> (c) H aborts its emulation of P before its call to H is emulated.

And thus didn't correctly emulate the behavior of a call H.

>
> [00001200][00101fae][00101fba] 83c408     add esp,+08   // return to
> executed P
> [00001203][00101fae][00101fba] 85c0       test eax,eax
> [00001205][00101fae][00101fba] 7402       jz 00001209
> [00001209][00101fb2][0000121d] 5d         pop ebp
> [0000120a][00101fb6][000011f0] c3         ret           // return from
> executed P
> [0000121d][00101fba][00000000] 83c404     add esp,+04
> [00001220][00101fba][00000000] 33c0       xor eax,eax
> [00001222][00101fbe][00100000] 5d         pop ebp
> [00001223][00101fc2][00000000] c3         ret           // ret from main
> Number of Instructions Executed(878) / 67 = 13 pages
>
>
>