XPost: comp.theory, sci.logic
From: flibble@red-dwarf.jmc.corp
On Thu, 31 Jul 2025 07:32:14 -0400, Richard Damon wrote:
> On 7/30/25 11:38 PM, olcott wrote:
>> 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.
>
> Doesn't mean that is what you are to do.
>
> HHH is supposed to simulate DDD, and all of DDD which include HHH, to
> determine what that program will do.
>
> Since HHH does a CONDINTIONAL simulation of its input, it is important
> to keep track of that conditionality. Something you forget when you stop
> looking at the trace of it, and only at the trace of what it is doing,
> something that has no bearing on the behavior of the simulated HHH.
>
>
>>
>>>> https://en.wikipedia.org/wiki/Cooperative_multitasking
>>>>
>>>>
>>
>
> So, you admit that you talking about multi-tasking was irrelevent.
>
>
>>
>>>
>>>> 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.
>
> Who said that?
>
> The problem is the question is what the first level DDD does, which has
> code, from HHH, to CONDITIONALLY simulate a copy of itself.
>
> Since that code will abort the simulation if it thinks it will not be
> halting,
>
>
>> People cold honestly believe that this is impossible entirely on the
>> basis of their lack of sufficient technical competence.
>
> No, people see that *YOUR* implementation gets the wrong answer, because
> you assume a wrong criteria\.
>
>
> Oh, and this multi-tasling system wzs very badly done, as it forces all
> the code to use the same memory space. Maybe that is because your
> experience was with older processors that couldn't handle themselves the
> seperate memory spacee. Note, the code of x86utm that you started with
> didn't require that the code being simulated be at the physical memory
> address that it represents, That limitation is something you added to
> the system because you apparently don't understand the abstraction of
> virtual addresses.
>
>
>>> 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.
>
> And that behavior is DEFINED to be what it does when RUN, or COMPLETELY
> simulted.
>
> SInce that WILL HALT, DDD is HALTING, and saying anything else is just a
> lie.
>
> That HHH doesn't simulate it to that point, is an error in HHH, not a
> problem with DDD.
>
>
>>
>>>> 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.
>
> No it isn't.
>
> You may be trying to implement it that way, but DDD is DEFINED as a
> totally independent process, which HHH is trying to determine what it
> will do by looking at its code.
>
>
>>
>>>> _DDD()
>>>> [0000219e] 55 push ebp [0000219f] 8
ec 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.
>
> Thats YOUR problem.
>
> LYING about what happens, just shows that you are a liar.
>
>
>> So far not one person here could ever understand one half of one page
>> of text when given three years to understand it.
>
> No, the one person here that doesn't understand that trace is YOU.
>
> Because you keep on lying to yourself about what you are doing.
This is an ad hominem attack as you have not finished your argumentation
that follows the attack (snipped).
/Flibble
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
