XPost: comp.theory, sci.logic
From: polcott333@gmail.com
On 7/30/2025 9:26 PM, Richard Damon wrote:
> On 7/30/25 10:08 PM, olcott wrote:
>> On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
>> > In comp.theory olcott wrote:
>>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>>>
>>>> It is not any lack of technical ability that determines
>>>> whether or not DDD correctly simulated by HHH can or
>>>> cannot reach its own "return" instruction final halt state.
>>>
>>> It is a lack of technical ability on your part which is unable to judge
>>> whether such a correct simulation is possible. Everybody else sees that
>>> it is not, so further questions about it are non-sensical.
>>>
>>
>> The notion of cooperative multi-tasking should be fully
>> understood by anyone with a computer science degree. If
>> most people here have much less than that then this may
>> be very difficult to understand.
>
> Sure, but you don't "trace" a program by going cross process.
>
DDD and HHH retain the exact same machine addresses
thus can be traced across processes.
>>
>> https://en.wikipedia.org/wiki/Cooperative_multitasking
>>
>
>>
>> The x86utm operating system that I wrote uses cooperative
>> multi-tasking. It enables any C function to emulate the
>> x86 machine language of another other C function in debug
>> step mode.
>
> So? What does that have to do with the correct simulation of one
> specific program?
>
If people here have much less than a computer science
degree and have never heard of any kind of multi-tasking
that may lead them to believe that HHH cannot emulate
itself emulating DDD.
People cold honestly believe that this is impossible
entirely on the basis of their lack of sufficient
technical competence.
> When simulating DDD, we need to look at each instruciton executed in the
> context of THAT PROCESS. That will watch every instruction of the HHH
> that it calls and is thus part of that process.
>
> We watch HHH doing the simulation, not the results of that simulation
>
Right if you want to see the actual behavior of DDD
you must make sure to not look at this behavior because
that might mislead you into telling the truth.
>>
>> Before it does this it creates a separate simulation
>> context having its own set of 16 virtual registers and
>> its own virtual stack.
>
> Right, which isn't part of the program being simulated,
>
HHH is the master process of all processes.
DDD is the immediate slave process.
>>
>> _DDD()
>> [0000219e] 55 push ebp
>> [0000219f] 8bec mov ebp,esp
>> [000021a1] 689e210000 push 0000219e // push DDD
>> [000021a6] e843f4ffff call 000015ee // call HHH
>> [000021ab] 83c404 add esp,+04
>> [000021ae] 5d pop ebp
>> [000021af] c3 ret
>> Size in bytes:(0018) [000021af]
>
>
> Which isn't a program, and can't be simulated past the call instruction.
>
The recursive structure of DDD cannot be easily seen
when buried in hundreds of pages of extraneous detail.
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
>> HHH emulates DDD in a separate process context. When
>> this DDD calls HHH(DDD) the original HHH emulates this
>> HHH in the DDD process context.
>
> When it call HHH, that HHH is PART OF THE PROCESS OF DDD.
>
> Not something "new"
>
When HHH emulates DDD it creates a new process context
allocating memory for this process context. The first
simulated HHH uses this same new process context.
> You don't understand what you are talking about, but just add fluff and
> smoke to hide your lies.
>
It that was true you could point to an actual mistake.
That ignorant people think that your own misconceptions
are my mistake is their mistake.
>>
>> This emulated HHH creates yet another process context
>> to emulate its own DDD. When this DDD calls yet another
>> HHH(DDD) this provides enough execution trace that the
>> repeating pattern can be seen.
>
> Which we don't actually care about, what we care abput it the original
> process of DDD, which includes the HHH that it calls.
>
We only care about whether the original input to
HHH(DDD) can possibly reach its own simulated final
halt state.
We cannot possibly get there while some people
(through their ignorance) honestly believe that HHH
cannot possibly emulate itself emulating DDD.
When this *is* understood then we understand why
DDD correctly simulated by HHH cannot possibly halt.
>>
>> *The above is proven right here*
>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>
>> Directly executed HHH emulates DDD that calls an emulated HHH(DDD)
>> that emulates another DDD instance that calls another HHH(DDD).
>
> And the only emulation that is the emulation of the input is that first
> emulation, NOT any of the other levels of emulation.
>
*Counter-factual*
The executed HHH(DDD) emulates DDD and also emulates
another HHH in the same process context as this DDD.
This emulated HHH creates another process context and
emulates another DDD. This DDD calls another HHH(DDD)
in its same process context.
All of the above actually occurs in the fully operational code.
> Sorry, you are just proving you don't understand the basics of what a
> program is.
>
The notion of a program in C with global variables and such
is not what I am going for. That diverges from the Turing
model of computation.
If we merely examine all of the behavior that the input to
HHH(DDD) specifies it does specify exactly what I said above
in *Counter-factual*
The rest is merely you proving that you did not
understand the half page of text that you have
had three years to understand.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
