Re: DDD correctly emulated by H0 --- Why Lie?

On 6/23/24 6:45 PM, olcott wrote:

On 6/23/2024 5:35 PM, Richard Damon wrote:

On 6/23/24 6:04 PM, olcott wrote:

On 6/23/2024 4:49 PM, Richard Damon wrote:

On 6/23/24 5:41 PM, olcott wrote:

On 6/23/2024 1:20 PM, Richard Damon wrote:

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
>
According to the semantics of the x86 programming language
when DDD correctly emulated by H0 calls H0(DDD) this call
cannot possibly return.
>
Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.
>
Anyone disagreeing with these two statements is WRONG.
>

>
NOw, if you REALLY mean just can H0 simulate this input to a final state, the answer is WHO CARES.
>
But I will put out a few comments on errors in your presentation\.
>
First, if you ONLY have the bytes presented, then the answer becomes trivial, as H0 HAS to stop emulating when it gets to the call instruction, as there is no data at address 000015d2 defined to simulate.
>

>
What a God damned liar.
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>

>
Which begins its trace at main, not DDD:
>

>
You knew that there IS an HH0 and lied about it.
That makes you a God damned liar.
>
Of course C programs begin at main() Liar !!!
>

>
But you weren't talking about it, so your trace isn't the claimed trace, so you are again the LIAR.
>
>
You keep on talking about the decider taking as its input, the machine that calls it, and what THAT DECIDERS trace shows.
>
That will not begin with main.
>
THAT is the input that you NEED to show to "verify" your claim, and that you have never done.
>
So, you are just showing that either you don't know what you are talking about, or intentionally trying to use double speak to avoid revealing your error.
>
In the above program, if the listed bytes are all that is available, HHH0(DDD) absolutely can not trace more than 4 instructions.
>
Thus, to make you claim, the input can't be just what you show. PERIOD.
>
It must include all of the memory that the trace would go to, which means all of HHH0 and everything it calls, so when you change the decider, you have a different input, so can't equate them without lying.

 You know what the freak I was talking from prior
discussions unless your brain is so damaged that
you can remember anything from one post to the next.
 In the case that you affirm that your brain <is>
this damaged then I humbly apologize.
 

No, you don't know what you are talking about.
I pointed out that you claim to have verified that the decider can not correctly emulate the input to the return instruciton.
I point out that you have never shown such a decider correctly emulating the input past the CALL instruction.
YOU HAVEN'T, and when you call me a liar, as "proof" you show a trace that doesn't show anything like what you claim.
So, it is still demonstrated that the decider of the machine that calls the decider has ever been correctly emulated past the call instruction.
So, you are still shown to be a LIAR.