On 3/15/2024 12:39 PM, immibis wrote:
> On 15/03/24 18:18, olcott wrote:
>> On 3/15/2024 12:15 PM, immibis wrote:
>>> On 15/03/24 18:11, olcott wrote:
>>>> On 3/15/2024 12:06 PM, immibis wrote:
>>>>> On 15/03/24 15:17, olcott wrote:
>>>>>> On 3/15/2024 4:36 AM, Fred. Zwarts wrote:
>>>>>>> Op 15.mrt.2024 om 03:40 schreef olcott:
>>>>>>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>>>>>>> On 15/03/24 03:29, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy)
>>>>>>>>>> does*
>>>>>>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet the*
>>>>>>>>>> *original criteria because it does meet the above criteria*
>>>>>>>>>>
>>>>>>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>>>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied
>>>>>>>>>> to ⟨Ĥ⟩
>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the
>>>>>>>>>> process
>>>>>>>>>>
>>>>>>>>>> The earliest point when Turing machine H can detect the repeating
>>>>>>>>>
>>>>>>>>> Whensoever H detects the repeating state and aborts it is
>>>>>>>>> incorrect because the state is not repeating. The state is
>>>>>>>>> repeating if H does not detect the repeating state.
>>>>>>>>
>>>>>>>> You keep saying that H(D,D) never really needs to abort the
>>>>>>>> simulation of its input because after H(D,D) has aborted the
>>>>>>>> simulation of this input it no longer needs to be aborted.
>>>>>>>>
>>>>>>>
>>>>>>> Do you finally understand it? Hah(Dah,Dah) does not need to
>>>>>>> abort, because Dah halts. Hah should look at its input Dah (which
>>>>>>> aborts), not at its non-input Dss (which does not abort).
>>>>>>
>>>>>> Unless some H(D,D) aborts the simulation of its input D(D) never
>>>>>> stops
>>>>>> running. The outermost H(D,D) sees this abort criteria first. If the
>>>>>> outermost H(D,D) does not abort its simulation then none of them do.
>>>>>> therefore the outermost H(D,D) is correct to abort its simulation.
>>>>>>
>>>>>
>>>>> What does "some H(D,D)" mean? There is only one H(D,D).
>>>>
>>>> D(D) specifies an infinite chain of H(D,D) unless D(D) is aborted
>>>> at some point. The outermost H(D,D) always has seen a longer execution
>>>> trace than any of the inner ones.
>>>>
>>>
>>> D(D) only specifies one call to H(D,D). It is H's fault if H is
>>> unable to return a value without infinite recursion.
>>
>> This conversation has been moved to here:
>> [Proof that H(D,D) meets its abort criteria]
>>
>
> Strawman deflection ignored. D(D) only specifies one call to H(D,D). It
> is H's fault if H is unable to return a value without infinite recursion.

This conversation has been moved to here:
[Proof that H(D,D) meets its abort criteria]

After we have 100% complete closure on that point
then we can change back to H ⟨Ĥ⟩ ⟨Ĥ⟩.

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

On 3/15/2024 12:44 PM, Richard Damon wrote:
> On 3/15/24 10:11 AM, olcott wrote:
>> D(D) specifies an infinite chain of H(D,D) unless D(D) is aborted
>> at some point. The outermost H(D,D) always has seen a longer execution
>> trace than any of the inner ones.
>>
>
> Right, *AT SOME POINT* but not nessesarily HERE.
>
> No, the outermose has seen more execution trace then the innerones have
> at the point that H aborts their simulation.
>

I have moved the above dialogue to this to
[Proof that H(D,D) meets its abort criteria]

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

On 15/03/24 18:57, olcott wrote:
> On 3/15/2024 12:39 PM, immibis wrote:
>> On 15/03/24 18:18, olcott wrote:
>>> On 3/15/2024 12:15 PM, immibis wrote:
>>>> On 15/03/24 18:11, olcott wrote:
>>>>> On 3/15/2024 12:06 PM, immibis wrote:
>>>>>> On 15/03/24 15:17, olcott wrote:
>>>>>>> On 3/15/2024 4:36 AM, Fred. Zwarts wrote:
>>>>>>>> Op 15.mrt.2024 om 03:40 schreef olcott:
>>>>>>>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>>>>>>>> On 15/03/24 03:29, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy)
>>>>>>>>>>> does*
>>>>>>>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet
>>>>>>>>>>> the*
>>>>>>>>>>> *original criteria because it does meet the above criteria*
>>>>>>>>>>>
>>>>>>>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>>>>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩
>>>>>>>>>>> applied to ⟨Ĥ⟩
>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the
>>>>>>>>>>> process
>>>>>>>>>>>
>>>>>>>>>>> The earliest point when Turing machine H can detect the
>>>>>>>>>>> repeating
>>>>>>>>>>
>>>>>>>>>> Whensoever H detects the repeating state and aborts it is
>>>>>>>>>> incorrect because the state is not repeating. The state is
>>>>>>>>>> repeating if H does not detect the repeating state.
>>>>>>>>>
>>>>>>>>> You keep saying that H(D,D) never really needs to abort the
>>>>>>>>> simulation of its input because after H(D,D) has aborted the
>>>>>>>>> simulation of this input it no longer needs to be aborted.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Do you finally understand it? Hah(Dah,Dah) does not need to
>>>>>>>> abort, because Dah halts. Hah should look at its input Dah
>>>>>>>> (which aborts), not at its non-input Dss (which does not abort).
>>>>>>>
>>>>>>> Unless some H(D,D) aborts the simulation of its input D(D) never
>>>>>>> stops
>>>>>>> running. The outermost H(D,D) sees this abort criteria first. If the
>>>>>>> outermost H(D,D) does not abort its simulation then none of them do.
>>>>>>> therefore the outermost H(D,D) is correct to abort its simulation.
>>>>>>>
>>>>>>
>>>>>> What does "some H(D,D)" mean? There is only one H(D,D).
>>>>>
>>>>> D(D) specifies an infinite chain of H(D,D) unless D(D) is aborted
>>>>> at some point. The outermost H(D,D) always has seen a longer execution
>>>>> trace than any of the inner ones.
>>>>>
>>>>
>>>> D(D) only specifies one call to H(D,D). It is H's fault if H is
>>>> unable to return a value without infinite recursion.
>>>
>>> This conversation has been moved to here:
>>> [Proof that H(D,D) meets its abort criteria]
>>>
>>
>> Strawman deflection ignored. D(D) only specifies one call to H(D,D).
>> It is H's fault if H is unable to return a value without infinite
>> recursion.
>
> This conversation has been moved to here:
> [Proof that H(D,D) meets its abort criteria]
>
> After we have 100% complete closure on that point
> then we can change back to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>
Strawman deflection ignored. D(D) only specifies one call to H(D,D). It
is H's fault if H is unable to return a value without infinite recursion.

On 15/03/2024 11:47, Mikko wrote:
> On 2024-03-14 20:34:30 +0000, olcott said:
>
>> On 3/14/2024 8:46 AM, Mikko wrote:
>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>
>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>
>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>
>>>>> Do you have an get_code_end function? It is computable but
>>>>> far from trivial, especially if the return instruction that
>>>>> is usually at the end of the function is in the middle.
>>>>>
>>>>
>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>
>>> Who ensures that there are no NOPs elsewhere and that there always
>>> is one at the end?
>>>
>>
>> The compiler uses another byte that I replace with 0x90.
>
> Do you also verify that there is no 0x90 in the middle?
> And what was wrong with that other byte?
>

Just to answer your question, between functions MSVC pads with INT 3 instructions 0xcc, for "quick
rebuild" or maybe "edit and continue" support. That choice means if program control inadvertantly
or nefariously gets there, the program will break into a debugger (if present) or abort. PO
disassembles the code by using the x86 emulation software to execute each instruction in turn.
Since he has not initialised an IVT that would all go horribly wrong. His comment in the code says
the emulation software "gets confused" by 0xcc bytes...

Mike.

On 2024-03-16 01:15:54 +0000, Mike Terry said:

> On 15/03/2024 11:47, Mikko wrote:
>> On 2024-03-14 20:34:30 +0000, olcott said:
>>
>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>
>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>
>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>
>>>>>> Do you have an get_code_end function? It is computable but
>>>>>> far from trivial, especially if the return instruction that
>>>>>> is usually at the end of the function is in the middle.
>>>>>>
>>>>>
>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>
>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>> is one at the end?
>>>>
>>>
>>> The compiler uses another byte that I replace with 0x90.
>>
>> Do you also verify that there is no 0x90 in the middle?
>> And what was wrong with that other byte?
>>
>
> Just to answer your question, between functions MSVC pads with INT 3
> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
> support. That choice means if program control inadvertantly or
> nefariously gets there, the program will break into a debugger (if
> present) or abort. PO disassembles the code by using the x86 emulation
> software to execute each instruction in turn. Since he has not
> initialised an IVT that would all go horribly wrong. His comment in
> the code says the emulation software "gets confused" by 0xcc bytes...

As the INT 3 instruction is in a position that is not executed it should
not confuse the interpreter. And one can be sure that there are no INT 3
instructions in the program code.

--
Mikko

On 3/16/2024 10:56 AM, Mikko wrote:
> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>
>> On 15/03/2024 11:47, Mikko wrote:
>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>
>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>
>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>
>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>
>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>> far from trivial, especially if the return instruction that
>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>
>>>>>>
>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>
>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>> is one at the end?
>>>>>
>>>>
>>>> The compiler uses another byte that I replace with 0x90.
>>>
>>> Do you also verify that there is no 0x90 in the middle?
>>> And what was wrong with that other byte?
>>>
>>
>> Just to answer your question, between functions MSVC pads with INT 3
>> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
>> support.  That choice means if program control inadvertantly or
>> nefariously gets there, the program will break into a debugger (if
>> present) or abort.  PO disassembles the code by using the x86
>> emulation software to execute each instruction in turn. Since he has
>> not initialised an IVT that would all go horribly wrong.  His comment
>> in the code says the emulation software "gets confused" by 0xcc bytes...
>
> As the INT 3 instruction is in a position that is not executed it should
> not confuse the interpreter. And one can be sure that there are no INT 3
> instructions in the program code.
>

I checked my own notes on this.

u32 get_disassembly_listing(unsigned flags, COFF_Reader& Reader,
X86_UTM& x86utm)
{ // Microsoft "C" uses the the 0xCC "int 3" OpCode as a padding byte between
// functions. The x86emu disassembler gets confused by this padding
character
// so we change it to the 0x90 "nop" Opcode.
//printf("get_disassembly_listing()\n");

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

On 2024-03-15 17:11:52 +0000, olcott said:

> On 3/15/2024 12:06 PM, immibis wrote:
>> On 15/03/24 15:17, olcott wrote:
>>> On 3/15/2024 4:36 AM, Fred. Zwarts wrote:
>>>> Op 15.mrt.2024 om 03:40 schreef olcott:
>>>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>>>> On 15/03/24 03:29, olcott wrote:
>>>>>>>
>>>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy) does*
>>>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet the*
>>>>>>> *original criteria because it does meet the above criteria*
>>>>>>>
>>>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>>>>>>>
>>>>>>> The earliest point when Turing machine H can detect the repeating
>>>>>>
>>>>>> Whensoever H detects the repeating state and aborts it is incorrect
>>>>>> because the state is not repeating. The state is repeating if H does
>>>>>> not detect the repeating state.
>>>>>
>>>>> You keep saying that H(D,D) never really needs to abort the
>>>>> simulation of its input because after H(D,D) has aborted the
>>>>> simulation of this input it no longer needs to be aborted.
>>>>>
>>>>
>>>> Do you finally understand it? Hah(Dah,Dah) does not need to abort,
>>>> because Dah halts. Hah should look at its input Dah (which aborts), not
>>>> at its non-input Dss (which does not abort).
>>>
>>> Unless some H(D,D) aborts the simulation of its input D(D) never stops
>>> running. The outermost H(D,D) sees this abort criteria first. If the
>>> outermost H(D,D) does not abort its simulation then none of them do.
>>> therefore the outermost H(D,D) is correct to abort its simulation.
>>>
>>
>> What does "some H(D,D)" mean? There is only one H(D,D).
>
> D(D) specifies an infinite chain of H(D,D) unless D(D) is aborted
> at some point. The outermost H(D,D) always has seen a longer execution
> trace than any of the inner ones.

Trolls don't answer questions.

Some H(D,D) can be taken to mean some activation of H with arguments
D and D.

--
Mikko

On 2024-03-15 14:22:05 +0000, olcott said:

> On 3/15/2024 7:22 AM, Mikko wrote:
>> On 2024-03-15 02:40:20 +0000, olcott said:
>>
>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>> On 15/03/24 03:29, olcott wrote:
>>>>>
>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy) does*
>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet the*
>>>>> *original criteria because it does meet the above criteria*
>>>>>
>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>>>>>
>>>>> The earliest point when Turing machine H can detect the repeating
>>>>
>>>> Whensoever H detects the repeating state and aborts it is incorrect
>>>> because the state is not repeating. The state is repeating if H does
>>>> not detect the repeating state.
>>>
>>> You keep saying that H(D,D) never really needs to abort the
>>> simulation of its input because after H(D,D) has aborted the
>>> simulation of this input it no longer needs to be aborted.
>>
>> Why not? It is true. One aborting is enough.
>>
>
> Unless some H(D,D) aborts the simulation of its input D(D) never stops
> running. The outermost H(D,D) sees this abort criteria first. If the
> outermost H(D,D) does not abort its simulation then none of them do.
> Therefore the outermost H(D,D) is correct to abort its simulation.
>
> When the outermost H(D,D) aborts its simulation then the whole chain
> is simulation is completely stopped.

Nice to see that yuu agree.

--
Mikko

On 3/16/2024 11:05 AM, Mikko wrote:
> On 2024-03-15 14:22:05 +0000, olcott said:
>
>> On 3/15/2024 7:22 AM, Mikko wrote:
>>> On 2024-03-15 02:40:20 +0000, olcott said:
>>>
>>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>>> On 15/03/24 03:29, olcott wrote:
>>>>>>
>>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy) does*
>>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet the*
>>>>>> *original criteria because it does meet the above criteria*
>>>>>>
>>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>>>>>>
>>>>>> The earliest point when Turing machine H can detect the repeating
>>>>>
>>>>> Whensoever H detects the repeating state and aborts it is incorrect
>>>>> because the state is not repeating. The state is repeating if H
>>>>> does not detect the repeating state.
>>>>
>>>> You keep saying that H(D,D) never really needs to abort the
>>>> simulation of its input because after H(D,D) has aborted the
>>>> simulation of this input it no longer needs to be aborted.
>>>
>>> Why not? It is true. One aborting is enough.
>>>
>>
>> Unless some H(D,D) aborts the simulation of its input D(D) never stops
>> running. The outermost H(D,D) sees this abort criteria first. If the
>> outermost H(D,D) does not abort its simulation then none of them do.
>> Therefore the outermost H(D,D) is correct to abort its simulation.
>>
>> When the outermost H(D,D) aborts its simulation then the whole chain
>> is simulation is completely stopped.
>
> Nice to see that yuu agree.
>

I can't tell what you agree with.

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

On 16/03/2024 15:56, Mikko wrote:
> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>
>> On 15/03/2024 11:47, Mikko wrote:
>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>
>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>
>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>
>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>
>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>> far from trivial, especially if the return instruction that
>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>
>>>>>>
>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>
>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>> is one at the end?
>>>>>
>>>>
>>>> The compiler uses another byte that I replace with 0x90.
>>>
>>> Do you also verify that there is no 0x90 in the middle?
>>> And what was wrong with that other byte?
>>>
>>
>> Just to answer your question, between functions MSVC pads with INT 3 instructions 0xcc, for "quick
>> rebuild" or maybe "edit and continue" support.  That choice means if program control inadvertantly
>> or nefariously gets there, the program will break into a debugger (if present) or abort.  PO
>> disassembles the code by using the x86 emulation software to execute each instruction in turn.
>> Since he has not initialised an IVT that would all go horribly wrong.  His comment in the code
>> says the emulation software "gets confused" by 0xcc bytes...
>
> As the INT 3 instruction is in a position that is not executed it should
> not confuse the interpreter. And one can be sure that there are no INT 3
> instructions in the program code.
>

ok I was skipping bits...

So PO wants a disassembly of /the entire code range/ for reference purposes, which includes the INT
3 (software breakpoint) instructions. He does not have a "disassemble" routine, but he has an
"execute instruction" routine which as a byproduct produces a disassembly string for the
instruction. So he loops through all the code address range calling "execute instruction" and
incrementing the address by the executed instruction length each time. He is not tracing actual
code execution, and just wants the disassembly text. So he encounters the INT 3. (Yes, he could
have just handled disassembly for INT 3 as a special case instead of trying to execute them...).

I doubt there's any guarantee that there will be INT 3 padding between functions - e.g. I don't
think the compiler does that for Release (optimised) mode. Also no guarantee regarding NOPs in the
middle of a function, but there's loads of stuff like this all through the code - it's coded
specifically to handle what actually appears in PO's H,D,HH,H1,D1,...etc. that he has coded himself
and needs to run. Whenever something unexpected appears that's not been seen before, he adds
further code to x86utm to handle that. (I guess we've all written some programs like that!)

Mike.

On 3/16/2024 5:57 PM, Mike Terry wrote:
> On 16/03/2024 15:56, Mikko wrote:
>> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>>
>>> On 15/03/2024 11:47, Mikko wrote:
>>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>>
>>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>>
>>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>>
>>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>>
>>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>>> far from trivial, especially if the return instruction that
>>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>>
>>>>>>>
>>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>>
>>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>>> is one at the end?
>>>>>>
>>>>>
>>>>> The compiler uses another byte that I replace with 0x90.
>>>>
>>>> Do you also verify that there is no 0x90 in the middle?
>>>> And what was wrong with that other byte?
>>>>
>>>
>>> Just to answer your question, between functions MSVC pads with INT 3
>>> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
>>> support.  That choice means if program control inadvertantly or
>>> nefariously gets there, the program will break into a debugger (if
>>> present) or abort.  PO disassembles the code by using the x86
>>> emulation software to execute each instruction in turn. Since he has
>>> not initialised an IVT that would all go horribly wrong.  His comment
>>> in the code says the emulation software "gets confused" by 0xcc bytes...
>>
>> As the INT 3 instruction is in a position that is not executed it should
>> not confuse the interpreter. And one can be sure that there are no INT 3
>> instructions in the program code.
>>
>
> ok I was skipping bits...
>
> So PO wants a disassembly of /the entire code range/ for reference
> purposes, which includes the INT 3 (software breakpoint) instructions.
> He does not have a "disassemble" routine, but he has an "execute
> instruction" routine which as a byproduct produces a disassembly string
> for the instruction.  So he loops through all the code address range
> calling "execute instruction" and incrementing the address by the
> executed instruction length each time.  He is not tracing actual code
> execution, and just wants the disassembly text.  So he encounters the
> INT 3.  (Yes, he could have just handled disassembly for INT 3 as a
> special case instead of trying to execute them...).
>

It was only intended as padding so this wold be incorrect.

> I doubt there's any guarantee that there will be INT 3 padding between
> functions - e.g. I don't think the compiler does that for Release
> (optimised) mode.  Also no guarantee regarding NOPs in the middle of a
> function, but there's loads of stuff like this all through the code -

_HH()
[00001342] 55 push ebp
[00001343] 8bec mov ebp,esp
[00001345] 83ec24 sub esp,+24
[00001348] eb08 jmp 00001352
[0000134a] 90 nop
[0000134b] 90 nop
[0000134c] 90 nop
[0000134d] 90 nop

End_Of_Code is computed differently in HH.

> it's coded specifically to handle what actually appears in PO's
> H,D,HH,H1,D1,...etc. that he has coded himself and needs to run.
> Whenever something unexpected appears that's not been seen before, he
> adds further code to x86utm to handle that.  (I guess we've all written
> some programs like that!)
>
>
> Mike.

Accurate review.

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

On 16/03/24 23:57, Mike Terry wrote:
> On 16/03/2024 15:56, Mikko wrote:
>> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>>
>>> On 15/03/2024 11:47, Mikko wrote:
>>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>>
>>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>>
>>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>>
>>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>>
>>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>>> far from trivial, especially if the return instruction that
>>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>>
>>>>>>>
>>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>>
>>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>>> is one at the end?
>>>>>>
>>>>>
>>>>> The compiler uses another byte that I replace with 0x90.
>>>>
>>>> Do you also verify that there is no 0x90 in the middle?
>>>> And what was wrong with that other byte?
>>>>
>>>
>>> Just to answer your question, between functions MSVC pads with INT 3
>>> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
>>> support.  That choice means if program control inadvertantly or
>>> nefariously gets there, the program will break into a debugger (if
>>> present) or abort.  PO disassembles the code by using the x86
>>> emulation software to execute each instruction in turn. Since he has
>>> not initialised an IVT that would all go horribly wrong.  His comment
>>> in the code says the emulation software "gets confused" by 0xcc bytes...
>>
>> As the INT 3 instruction is in a position that is not executed it should
>> not confuse the interpreter. And one can be sure that there are no INT 3
>> instructions in the program code.
>>
>
> ok I was skipping bits...
>
> So PO wants a disassembly of /the entire code range/ for reference
> purposes, which includes the INT 3 (software breakpoint) instructions.
> He does not have a "disassemble" routine, but he has an "execute
> instruction" routine which as a byproduct produces a disassembly string
> for the instruction.  So he loops through all the code address range
> calling "execute instruction" and incrementing the address by the
> executed instruction length each time.  He is not tracing actual code
> execution, and just wants the disassembly text.  So he encounters the
> INT 3.  (Yes, he could have just handled disassembly for INT 3 as a
> special case instead of trying to execute them...).
>
> I doubt there's any guarantee that there will be INT 3 padding between
> functions - e.g. I don't think the compiler does that for Release
> (optimised) mode.  Also no guarantee regarding NOPs in the middle of a
> function, but there's loads of stuff like this all through the code -
> it's coded specifically to handle what actually appears in PO's
> H,D,HH,H1,D1,...etc. that he has coded himself and needs to run.
> Whenever something unexpected appears that's not been seen before, he
> adds further code to x86utm to handle that.  (I guess we've all written
> some programs like that!)
>
>
> Mike.
>

It's all irrelevant to the main point anyway. If his compiler does
produce this instruction, that's fine.

On 3/16/2024 6:46 PM, immibis wrote:
> On 16/03/24 23:57, Mike Terry wrote:
>> On 16/03/2024 15:56, Mikko wrote:
>>> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>>>
>>>> On 15/03/2024 11:47, Mikko wrote:
>>>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>>>
>>>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>>>
>>>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>>>
>>>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>>>> far from trivial, especially if the return instruction that
>>>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>>>
>>>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>>>> is one at the end?
>>>>>>>
>>>>>>
>>>>>> The compiler uses another byte that I replace with 0x90.
>>>>>
>>>>> Do you also verify that there is no 0x90 in the middle?
>>>>> And what was wrong with that other byte?
>>>>>
>>>>
>>>> Just to answer your question, between functions MSVC pads with INT 3
>>>> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
>>>> support.  That choice means if program control inadvertantly or
>>>> nefariously gets there, the program will break into a debugger (if
>>>> present) or abort.  PO disassembles the code by using the x86
>>>> emulation software to execute each instruction in turn. Since he has
>>>> not initialised an IVT that would all go horribly wrong.  His
>>>> comment in the code says the emulation software "gets confused" by
>>>> 0xcc bytes...
>>>
>>> As the INT 3 instruction is in a position that is not executed it should
>>> not confuse the interpreter. And one can be sure that there are no INT 3
>>> instructions in the program code.
>>>
>>
>> ok I was skipping bits...
>>
>> So PO wants a disassembly of /the entire code range/ for reference
>> purposes, which includes the INT 3 (software breakpoint) instructions.
>> He does not have a "disassemble" routine, but he has an "execute
>> instruction" routine which as a byproduct produces a disassembly
>> string for the instruction.  So he loops through all the code address
>> range calling "execute instruction" and incrementing the address by
>> the executed instruction length each time.  He is not tracing actual
>> code execution, and just wants the disassembly text.  So he encounters
>> the INT 3.  (Yes, he could have just handled disassembly for INT 3 as
>> a special case instead of trying to execute them...).
>>
>> I doubt there's any guarantee that there will be INT 3 padding between
>> functions - e.g. I don't think the compiler does that for Release
>> (optimised) mode.  Also no guarantee regarding NOPs in the middle of a
>> function, but there's loads of stuff like this all through the code -
>> it's coded specifically to handle what actually appears in PO's
>> H,D,HH,H1,D1,...etc. that he has coded himself and needs to run.
>> Whenever something unexpected appears that's not been seen before, he
>> adds further code to x86utm to handle that.  (I guess we've all
>> written some programs like that!)
>>
>>
>> Mike.
>>
>
> It's all irrelevant to the main point anyway. If his compiler does
> produce this instruction, that's fine.

Yes, that it is irrelevant supersedes all other views.

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

On 2024-03-16 16:00:29 +0000, olcott said:

> On 3/16/2024 10:56 AM, Mikko wrote:
>> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>>
>>> On 15/03/2024 11:47, Mikko wrote:
>>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>>
>>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>>
>>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>>
>>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>>
>>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>>> far from trivial, especially if the return instruction that
>>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>>
>>>>>>>
>>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>>
>>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>>> is one at the end?
>>>>>>
>>>>>
>>>>> The compiler uses another byte that I replace with 0x90.
>>>>
>>>> Do you also verify that there is no 0x90 in the middle?
>>>> And what was wrong with that other byte?
>>>>
>>>
>>> Just to answer your question, between functions MSVC pads with INT 3
>>> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
>>> support.  That choice means if program control inadvertantly or
>>> nefariously gets there, the program will break into a debugger (if
>>> present) or abort.  PO disassembles the code by using the x86 emulation
>>> software to execute each instruction in turn. Since he has not
>>> initialised an IVT that would all go horribly wrong.  His comment in
>>> the code says the emulation software "gets confused" by 0xcc bytes...
>>
>> As the INT 3 instruction is in a position that is not executed it should
>> not confuse the interpreter. And one can be sure that there are no INT 3
>> instructions in the program code.
>>
>
> I checked my own notes on this.
>
> u32 get_disassembly_listing(unsigned flags, COFF_Reader& Reader,
> X86_UTM& x86utm)
> {
> // Microsoft "C" uses the the 0xCC "int 3" OpCode as a padding byte between
> // functions. The x86emu disassembler gets confused by this padding character
> // so we change it to the 0x90 "nop" Opcode.
> //printf("get_disassembly_listing()\n");

How was the the disassembler confused? Did it not know the opcode?

--
Mikko

On 2024-03-16 22:57:24 +0000, Mike Terry said:

> On 16/03/2024 15:56, Mikko wrote:
>> On 2024-03-16 01:15:54 +0000, Mike Terry said:
>>
>>> On 15/03/2024 11:47, Mikko wrote:
>>>> On 2024-03-14 20:34:30 +0000, olcott said:
>>>>
>>>>> On 3/14/2024 8:46 AM, Mikko wrote:
>>>>>> On 2024-03-14 13:40:38 +0000, olcott said:
>>>>>>
>>>>>>> On 3/14/2024 5:50 AM, Mikko wrote:
>>>>>>>> On 2024-03-13 16:57:47 +0000, olcott said:
>>>>>>>>
>>>>>>>>>    u32 End_Of_Code   = get_code_end((u32)H);
>>>>>>>>
>>>>>>>> Do you have an get_code_end function? It is computable but
>>>>>>>> far from trivial, especially if the return instruction that
>>>>>>>> is usually at the end of the function is in the middle.
>>>>>>>>
>>>>>>>
>>>>>>> It looks for 0x90 NOP that pad the space between function bodies.
>>>>>>
>>>>>> Who ensures that there are no NOPs elsewhere and that there always
>>>>>> is one at the end?
>>>>>>
>>>>>
>>>>> The compiler uses another byte that I replace with 0x90.
>>>>
>>>> Do you also verify that there is no 0x90 in the middle?
>>>> And what was wrong with that other byte?
>>>>
>>>
>>> Just to answer your question, between functions MSVC pads with INT 3
>>> instructions 0xcc, for "quick rebuild" or maybe "edit and continue"
>>> support.  That choice means if program control inadvertantly or
>>> nefariously gets there, the program will break into a debugger (if
>>> present) or abort.  PO disassembles the code by using the x86 emulation
>>> software to execute each instruction in turn. Since he has not
>>> initialised an IVT that would all go horribly wrong.  His comment in
>>> the code says the emulation software "gets confused" by 0xcc bytes...
>>
>> As the INT 3 instruction is in a position that is not executed it should
>> not confuse the interpreter. And one can be sure that there are no INT 3
>> instructions in the program code.
>>
>
> ok I was skipping bits...
>
> So PO wants a disassembly of /the entire code range/ for reference
> purposes, which includes the INT 3 (software breakpoint) instructions.
> He does not have a "disassemble" routine, but he has an "execute
> instruction" routine which as a byproduct produces a disassembly string
> for the instruction. So he loops through all the code address range
> calling "execute instruction" and incrementing the address by the
> executed instruction length each time. He is not tracing actual code
> execution, and just wants the disassembly text. So he encounters the
> INT 3. (Yes, he could have just handled disassembly for INT 3 as a
> special case instead of trying to execute them...).
>
> I doubt there's any guarantee that there will be INT 3 padding between
> functions - e.g. I don't think the compiler does that for Release
> (optimised) mode. Also no guarantee regarding NOPs in the middle of a
> function, but there's loads of stuff like this all through the code -
> it's coded specifically to handle what actually appears in PO's
> H,D,HH,H1,D1,...etc. that he has coded himself and needs to run.
> Whenever something unexpected appears that's not been seen before, he
> adds further code to x86utm to handle that. (I guess we've all written
> some programs like that!)

Usually single step execution increments the instruction pointer by the
length of the instruction but there are exceptions. Call and int
instructions, put the address of the next instruction to stack instead
of the instruction pointer, jumps put it nowhere. So there are so many
special cases to handle that to add one more (INT 3) wouldn't change much.

--
Mikko

On 2024-03-16 16:23:58 +0000, olcott said:

> On 3/16/2024 11:05 AM, Mikko wrote:
>> On 2024-03-15 14:22:05 +0000, olcott said:
>>
>>> On 3/15/2024 7:22 AM, Mikko wrote:
>>>> On 2024-03-15 02:40:20 +0000, olcott said:
>>>>
>>>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>>>> On 15/03/24 03:29, olcott wrote:
>>>>>>>
>>>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy) does*
>>>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet the*
>>>>>>> *original criteria because it does meet the above criteria*
>>>>>>>
>>>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>>>>>>>
>>>>>>> The earliest point when Turing machine H can detect the repeating
>>>>>>
>>>>>> Whensoever H detects the repeating state and aborts it is incorrect
>>>>>> because the state is not repeating. The state is repeating if H does
>>>>>> not detect the repeating state.
>>>>>
>>>>> You keep saying that H(D,D) never really needs to abort the
>>>>> simulation of its input because after H(D,D) has aborted the
>>>>> simulation of this input it no longer needs to be aborted.
>>>>
>>>> Why not? It is true. One aborting is enough.
>>>>
>>>
>>> Unless some H(D,D) aborts the simulation of its input D(D) never stops
>>> running. The outermost H(D,D) sees this abort criteria first. If the
>>> outermost H(D,D) does not abort its simulation then none of them do.
>>> Therefore the outermost H(D,D) is correct to abort its simulation.
>>>
>>> When the outermost H(D,D) aborts its simulation then the whole chain
>>> is simulation is completely stopped.
>>
>> Nice to see that yuu agree.
>>
>
> I can't tell what you agree with.

First things first: It would often help if you could tell what you
agree with.

--
Mikko

On 3/17/2024 9:07 AM, Mikko wrote:
> On 2024-03-16 16:23:58 +0000, olcott said:
>
>> On 3/16/2024 11:05 AM, Mikko wrote:
>>> On 2024-03-15 14:22:05 +0000, olcott said:
>>>
>>>> On 3/15/2024 7:22 AM, Mikko wrote:
>>>>> On 2024-03-15 02:40:20 +0000, olcott said:
>>>>>
>>>>>> On 3/14/2024 9:34 PM, immibis wrote:
>>>>>>> On 15/03/24 03:29, olcott wrote:
>>>>>>>>
>>>>>>>> *Actually it is the fact that the top H ⟨Ĥ⟩ ⟨Ĥ⟩ (not a copy) does*
>>>>>>>> *get this correctly that proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ does not meet the*
>>>>>>>> *original criteria because it does meet the above criteria*
>>>>>>>>
>>>>>>>> Execution trace of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> (1) H applied ⟨Ĥ⟩ ⟨Ĥ⟩ simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>> (2) which begins at simulated ⟨Ĥ.q0⟩
>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to Ĥ.H
>>>>>>>> (b) Ĥ.H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied
>>>>>>>> to ⟨Ĥ⟩
>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>>>>>>>>
>>>>>>>> The earliest point when Turing machine H can detect the repeating
>>>>>>>
>>>>>>> Whensoever H detects the repeating state and aborts it is
>>>>>>> incorrect because the state is not repeating. The state is
>>>>>>> repeating if H does not detect the repeating state.
>>>>>>
>>>>>> You keep saying that H(D,D) never really needs to abort the
>>>>>> simulation of its input because after H(D,D) has aborted the
>>>>>> simulation of this input it no longer needs to be aborted.
>>>>>
>>>>> Why not? It is true. One aborting is enough.
>>>>>
>>>>
>>>> Unless some H(D,D) aborts the simulation of its input D(D) never stops
>>>> running. The outermost H(D,D) sees this abort criteria first. If the
>>>> outermost H(D,D) does not abort its simulation then none of them do.
>>>> Therefore the outermost H(D,D) is correct to abort its simulation.
>>>>
>>>> When the outermost H(D,D) aborts its simulation then the whole chain
>>>> is simulation is completely stopped.
>>>
>>> Nice to see that yuu agree.
>>>
>>
>> I can't tell what you agree with.
>
> First things first: It would often help if you could tell what you
> agree with.
>

*We must achieve mutual agreement on this*
[Proof that H(D,D) meets its abort criteria] --self-evident truth--

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