Deutsch English Français Italiano |
<v5a9bi$smd4$3@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory,sci.logic Subject: Re: DDD correctly emulated by H0 --- Why Lie? Date: Sun, 23 Jun 2024 18:58:58 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <v5a9bi$smd4$3@i2pn2.org> References: <v598l4$c4if$1@dont-email.me> <v59p13$smd5$1@i2pn2.org> <v5a4qc$h08n$1@dont-email.me> <v5a5a1$smd5$6@i2pn2.org> <v5a657$hgsg$1@dont-email.me> <v5a7vs$smd4$2@i2pn2.org> <v5a8hi$hsjd$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 23 Jun 2024 22:58:58 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="940452"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: <v5a8hi$hsjd$1@dont-email.me> X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US Bytes: 4898 Lines: 99 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.