XPost: comp.theory, sci.logic
From: news.x.richarddamon@xoxy.net
On 7/21/25 5:49 PM, olcott wrote:
> On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>>
>> In comp.theory olcott wrote:
>>> On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
>>>> olcott wrote:
>>>>> On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
>>>>>> olcott wrote:
>>>>>>> On 7/21/2025 4:06 AM, Mikko wrote:
>>>>>>>> On 2025-07-20 11:48:37 +0000, Mr Flibble said:
>>
>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
>>
>>>>>> [ .... ]
>>
>>>>>>>>>> Your problem is you don't understand the meaning of the words
>>>>>>>>>> you are
>>>>>>>>>> using.
>>
>>>>>>>>> This is an ad hominem attack, not argumentation.
>>
>>>>>>>> It is also honest and truthful, which is not as common as it
>>>>>>>> should.
>>
>>
>>>>>>> It is also honest and truthful that people
>>>>>>> that deny verified facts are either liars
>>>>>>> or lack sufficient technical competence.
>>
>>>>>> What you call "verified facts" are generally nothing of the kind.
>>>>>> They
>>>>>> are merely things, often false, you would like to be true.
>>
>>
>>
>>>>> *One key example of a denied verified fact is when Joes said*
>>
>>>>> On 7/18/2025 3:49 AM, joes wrote:
>>>>>> very obvious that HHH cannot simulate
>>>>>> DDD past the call to HHH.
>>
>>>> Joes is quite right, here, as has been said to you many times over by
>>>> several people.
>>
>>>>> HHH(DDD) does emulate itself emulating DDD
>>
>>>> You will have a get out clause from the vagueness of your language,
>>>> which
>>>> could be construed to mean practically anything.
>>
>>> typedef void (*ptr)();
>>> int HHH(ptr P);
>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>
>>> int main()
>>> {
>>> HHH(DDD);
>>> }
>>
>>> Not at all. HHH does emulate the x86 machine code
>>> of DDD pointed to by P. That is does this according
>>> to the semantics of the x86 language conclusively
>>> proves that this emulation is correct.
>>
>> That's nauseatingly overstretching things into another lie. Whatever HHH
>> might do is far short of sufficient "conclusively to prove" that the
>> emulation is correct. To prove that is likely impossible in principle,
>> that's even assuming you could define "correct" coherently.
>>
>
> [00002192] 55 push ebp
> [00002193] 8bec mov ebp,esp
> [00002195] 6892210000 push 00002192
> [0000219a] e833f4ffff call 000015d2 // call HHH
> [0000219f] 83c404 add esp,+04
> [000021a2] 5d pop ebp
> [000021a3] c3 ret
> Size in bytes:(0018) [000021a3]
Which isn't a program, you need to include the code for HHH.
That error means this input isn't runnable or simulatable as is.
>
> x86utm is a multi-tasking operating system (that I wrote)
> that allows any C function to execute any other C function
> in debug step mode. HHH and DDD have their own virtual
> registers and stack.
NO they don't, the HHH that DDD calls use the same set, as that HHH is
part of the program DDD.
>
> When HHH emulates the first instruction of DDD it
> emulates pushing the DDD ebp base pointer onto the
> DDD stack.
Right, but it can't emulated the call HHH and the following instruciton
using just that input.
Thus, you LIE about what the input is.
>
> *That is a 100% concrete example of correct emulation*
Nope, it is just PARTIAL correct emulation, as it missed the last part
of the instruction, which is to execute/simulate the next one.
>
> Exactly how is it that you could have construed this
> as impossible in principle?
>
>
The "impossible" part is for HHH to simulate the code of HHH per the x86
lamgage without it being part of its input.
OR for it to be different than the code of the HHH that DDD was built to
call and be at the same address (thus, if you can simulate the code of
HHH, it is ALWAYS the same code for a given "input" DDD, and there is no
"infinite set of HHHs" that see the same DDD, they each see a DIFFERENT
one, and thus you can't compare the results.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
