| Deutsch English Français Italiano |
|
<2f87c70ff64c8b83fa2456545e3250930158a3b5@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory Subject: Re: Halting Problem: What Constitutes Pathological Input Date: Wed, 7 May 2025 07:01:17 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <2f87c70ff64c8b83fa2456545e3250930158a3b5@i2pn2.org> References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvamqc$o6v5$4@dont-email.me> <vvan7q$o4v0$1@dont-email.me> <ts5SP.113145$_Npd.41800@fx01.ams4> <vvat0g$vtiu$1@dont-email.me> <vvatf3$o4v0$3@dont-email.me> <vvaut0$vtiu$4@dont-email.me> <vvav6o$o4v0$4@dont-email.me> <vvb329$15u5b$1@dont-email.me> <vvb37g$1451r$1@dont-email.me> <vvb43f$15u5b$4@dont-email.me> <vvb4ok$o4v0$9@dont-email.me> <vvb52g$15u5b$6@dont-email.me> <vvb5ca$o4v0$10@dont-email.me> <vvb5vp$15u5b$7@dont-email.me> <vvb675$o4v0$11@dont-email.me> <vvb9d7$1av94$3@dont-email.me> <vvbani$1b6l1$1@dont-email.me> <vvbb6s$1av94$4@dont-email.me> <vvbcb3$1b6l1$2@dont-email.me> <vvbe0j$1av94$8@dont-email.me> <vvbecc$1b6l1$6@dont-email.me> <vvbhk0$1ijna$1@dont-email.me> <vvc7t9$29pp8$1@dont-email.me> <vvc86c$2a4cs$1@dont-email.me> <vvcufi$2sk4a$3@dont-email.me> <vvdlff$3i09b$2@dont-email.me> <vvdmqe$3huo6$4@dont-email.me> <vvdneq$3k2gc$3@dont-email.me> <42d875b9727dae90799e064ac33b9e1be866f2b5@i2pn2.org> <vvegg3$89u0$7@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 7 May 2025 11:13:31 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="3507609"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: <vvegg3$89u0$7@dont-email.me> X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 5906 Lines: 109 On 5/6/25 10:28 PM, olcott wrote: > On 5/6/2025 5:59 PM, Richard Damon wrote: >> On 5/6/25 3:20 PM, olcott wrote: >>> On 5/6/2025 2:10 PM, Fred. Zwarts wrote: >>>> Op 06.mei.2025 om 20:47 schreef olcott: >>>>> On 5/6/2025 7:14 AM, dbush wrote: >>>>>> On 5/6/2025 1:54 AM, olcott wrote: >>>>>>> On 5/6/2025 12:49 AM, Richard Heathfield wrote: >>>>>>>> On 06/05/2025 00:29, olcott wrote: >>>>>>>> >>>>>>>> <snip> >>>>>>>> >>>>>>>>> >>>>>>>>> It is the problem incorrect specification that creates >>>>>>>>> the contradiction. >>>>>>>> >>>>>>>> Not at all. The contradiction arises from the fact that it is >>>>>>>> not possible to construct a universal decider. >>>>>>>> >>>>>>>>> Everyone here insists that functions computed >>>>>>>>> by models of computation can ignore inputs and >>>>>>>>> base their output on something else. >>>>>>>> >>>>>>>> I don't think anyone's saying that. >>>>>>>> >>>>>>>> Maybe you don't read so well. >>>>>>>> >>>>>>> >>>>>>> What are the exact steps for DD to be emulated by HHH >>>>>>> according to the semantics of the x86 language? >>>>>>> *Only an execution trace will do* >>>>>> >>>>>> The exact same steps for DD to be emulated by UTM. >>>>>> >>>>> >>>>> _DD() >>>>> [00002133] 55 push ebp ; housekeeping >>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>> [00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD >>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD) >>>>> [00002141] 83c404 add esp,+04 >>>>> [00002144] 8945fc mov [ebp-04],eax >>>>> [00002147] 837dfc00 cmp dword [ebp-04],+00 >>>>> [0000214b] 7402 jz 0000214f >>>>> [0000214d] ebfe jmp 0000214d >>>>> [0000214f] 8b45fc mov eax,[ebp-04] >>>>> [00002152] 8be5 mov esp,ebp >>>>> [00002154] 5d pop ebp >>>>> [00002155] c3 ret >>>>> Size in bytes:(0035) [00002155] >>>>> >>>>> Machine address by machine address specifics >>>>> that you know that you cannot provide because >>>>> you know that you are wrong. >>>>> >>>> >>>> That you do not understand it, does not mean that it has not been >>>> provided to you. It has, many times. If you do not know that you are >>>> wrong, you must be very stupid. >>> >>> Everything besides a machine address by machine >>> address of DD emulated by HHH (according to the >>> rules of the x86 language) where the emulated >>> DD reaches its own "ret" instruction >> >> In other words, if people don't agree with your fantasy that is just >> in error, then "they" must be wrong. >> >> No, it >> >>> >>> *IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION* >> >> No, YOU are a dishoneast dodge from the actual question >> >>> >>> Most of my reviewers switch to rhetoric when they >>> know that they are wrong and still want to disagree. >>> Disagreement (not truth) is their highest priority. >>> >> >> Nope, that is just you projecting again. > > You keep saying the DD emulated by HHH according > to the rules of the x86 language is wrong. Right, because it stops wnen it should not. > > You keep arguing that HHH is required to break these > rules to conform with the common misconception that HHH > is required to report on the direct execution of DD(). No, it needs to keep to them, which it doesn\'t. Where did I say it must break the rules? > > How the Hell can breaking the rules specified > by the x86 language possibly be correct? > Right, how in hell do you call HHH stopping its emulation at the call instruction correct when it is a violation of teh x86 language? YOU are the damned liar, and you prove it with your own arguements. The x86 language doesn't give your exemption "unless it would not halt unless aborted", that is your equivocation you use to make your iie.