On 8/2/24 1:57 PM, olcott wrote:
On 8/2/2024 12:39 PM, Mike Terry wrote:
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
machine stack stack machine assembly >>>>>>>>>>>> address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>> [00002192][00103820][00000000] 55 push ebp >>>>>>>>>>>> [00002193][00103820][00000000] 8bec mov ebp,esp >>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>>> call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an
unconditional simulator that does not abort.
This algorithm is used by all the simulating termination
analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
*If simulating halt decider H correctly simulates its >>>>>>>>>> input D*
*until H correctly determines that its simulated D would >>>>>>>>>> never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an
incorrect simulation that violates the semantics of the x86
language by skipping the last few instructions of a halting
program.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates
itself correctly. So, talking about a correct simulation by HHH
is vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got
critic, because you keep hiding important properties of HHH,
which made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any
self-reflection. It has been pointed out that there are many errors
in this proof.
Why repeating such errors?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation Execution Trace Stored
at:1138cc
[00002172][001138bc][001138c0] 55 push ebp ; >>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ;
housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion. >>>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
[0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops"
within his "computing model". (Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not in
the user code DDD/HHH/etc. in the obj file, and so we would not expect
to see any trace entries for its internals. When the op concludes,
rax has the address of the allocated memory, which is consistent with
how a normal function would have returned the address.
You can say correctly that PO has not explained this, but then he
provided the full trace under protest, so it's understandable that he
has not previously explained everything in it. I'm surprised that his
response to your post was both to ignore the question and accuse you
of playing sadistic head games, as the question was perfectly sensible.
The freaking point is that I conclusively
proved that HHH, and HH have always been
correct x86 emulators
EVEN IF THEY DO THIS BY WILD GUESS
The resulting execution trace of DDD and DD has proven
that this trace is correct for three freaking years.
You can look up the 777 address in the listing at the start of the
trace and it's there along with a bunch of other routines which appear
to just return without doing anything - those are all PO's primitive
ops. If you feel a need to understand exactly what they do, you'll
need to check his source code! (Although for Allocate there is no big
surprise...)
So your observation isn't really a problem beyond not being properly
explained. An actual problem seen in his trace data is that the
simulation of DDD does not track the behaviour of the unsimulated DDD.
I.e. his simulation is incorrect. (PO knows about that but claims it
doesn't matter, although on other occasions he still claims the
simulation is correct.)
Mike.
The resulting execution trace of DDD emulated by HHH
proves that it is correct for three freaking years.
T
But the fact that there IS NO TRACE of DDD emulated by HHH that is
correct, just proves you are wrong.
The big trace you provide is NOT DDD emulated by HHH ,HHH, but main/HHH emulated by x86utm.
And the short traces you provide don't show HHH emulating the code of
the call HHH correctly, as it omits the code of the HHH that it see
calls, but instead INCORRECTLY considers it as a unconditional emulation (popped up a level) of the input. If HHH is actually an unconditional
emulator, it can not abort, and if it can abort, it is not an
unconditional emulator and the transform is just invalid.
Thus, all you have done is proven you have been lying about things for
years, and ignored all the corrections you have been given, resulting in
the clear fact that you are just recklessly disregarding the truth to
maintain your lies, making you just an ignorant pathological liar.
Sorry, but that is just the honest truth, and until you see that, you
are just heaping all your ideas into the trash heap of logic, where
perhaps you will spend the rest of your eternity.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)