Deutsch English Français Italiano |
<v700c0$289t$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko <mikko.levanto@iki.fi> Newsgroups: comp.theory Subject: Re: Liar detector: Fred, Richard, Joes and Alan --- Ben's agreement Date: Sun, 14 Jul 2024 10:56:48 +0300 Organization: - Lines: 127 Message-ID: <v700c0$289t$1@dont-email.me> References: <v644pn$29t4h$3@dont-email.me> <v68tvd$3ac9t$1@dont-email.me> <v68uj0$3ahel$1@dont-email.me> <v694k4$3bevk$1@dont-email.me> <v69502$3bh3f$1@dont-email.me> <v6b1k4$3odj5$1@dont-email.me> <v6bf7r$3qiio$2@dont-email.me> <v6bm5v$3rj8n$1@dont-email.me> <v6bmoe$3ri0l$2@dont-email.me> <v6bnt2$3rj8n$3@dont-email.me> <v6brfj$3skuk$2@dont-email.me> <v6c3vh$3ttem$1@dont-email.me> <v6c539$3u2mj$1@dont-email.me> <v6dda0$7s8u$1@dont-email.me> <v6e67v$bbcb$4@dont-email.me> <v6gss2$t87a$1@dont-email.me> <v6gv65$to0m$1@dont-email.me> <v6h2li$ud7p$1@dont-email.me> <v6h2rm$ue7s$1@dont-email.me> <v6h3cu$ud7p$2@dont-email.me> <v6h83q$vag9$1@dont-email.me> <v6ikgb$19f5g$1@dont-email.me> <v6jgjo$1ctoi$4@dont-email.me> <v6lckp$1qi9e$1@dont-email.me> <v6m2qq$1tj30$6@dont-email.me> <v6nvc8$2blka$1@dont-email.me> <v6opg3$2fuva$6@dont-email.me> <v6qnif$2udsp$1@dont-email.me> <v6r9rg$30qtt$6@dont-email.me> <v6tbdc$3ge2u$1@dont-email.me> <v6tq47$3imib$4@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 14 Jul 2024 09:56:49 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9a92efa79bf89cf93bddcd1bb941165c"; logging-data="74045"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rkGWriZSkkGOl6YCflyYA" User-Agent: Unison/2.2 Cancel-Lock: sha1:CR+kPecVkIBby1qqiMSZPlGFmuo= Bytes: 6587 On 2024-07-13 11:57:59 +0000, olcott said: > On 7/13/2024 2:46 AM, Mikko wrote: >> On 2024-07-12 13:07:59 +0000, olcott said: >> >>> On 7/12/2024 2:55 AM, Mikko wrote: >>>> On 2024-07-11 14:16:34 +0000, olcott said: >>>> >>>>> On 7/11/2024 1:50 AM, Mikko wrote: >>>>>> On 2024-07-10 13:37:30 +0000, olcott said: >>>>>> >>>>>>> On 7/10/2024 2:18 AM, Mikko wrote: >>>>>>>> On 2024-07-09 14:14:16 +0000, olcott said: >>>>>>>> >>>>>>>>> On 7/9/2024 1:14 AM, Mikko wrote: >>>>>>>>>> On 2024-07-08 17:36:58 +0000, olcott said: >>>>>>>>>> >>>>>>>>>>> On 7/8/2024 11:16 AM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 08.jul.2024 om 18:07 schreef olcott: >>>>>>>>>>>>> >>>>>>>>>>>>> Try to show how infinity is one cycle too soon. >>>>>>>>>>>>> >>>>>>>>>>>> You believe that two equals infinity. >>>>>>>>>>> >>>>>>>>>>> void Infinite_Loop() >>>>>>>>>>> { >>>>>>>>>>> HERE: goto HERE; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> void Infinite_Recursion() >>>>>>>>>>> { >>>>>>>>>>> Infinite_Recursion(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> void DDD() >>>>>>>>>>> { >>>>>>>>>>> HHH(DDD); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Two cycles is enough to correctly determine that none >>>>>>>>>>> of the above functions correctly emulated by HHH can >>>>>>>>>>> possibly halt. >>>>>>>>>>> >>>>>>>>>>> That you don't see this is ignorance or deception. >>>>>>>>>> >>>>>>>>>> There is an important detail that determines whether an infinite >>>>>>>>>> execution can be inferred. That is best illustrated by the following >>>>>>>>>> examples: >>>>>>>>>> >>>>>>>>>> void Finite_Loop() >>>>>>>>>> { >>>>>>>>>> int x = 10000; >>>>>>>>>> HERE: >>>>>>>>>> if (x > 0) { >>>>>>>>>> x--; >>>>>>>>>> goto HERE; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> void Finite_Recursion(int n) >>>>>>>>>> { >>>>>>>>>> if (n > 0) { >>>>>>>>>> Finite_Recursion(n + 1); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> void DDD() >>>>>>>>>> { >>>>>>>>>> HHH(DDD); // HHH detects recursive simulation and then simulates no more >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> The important difference is that in my examples there is a conditional >>>>>>>>>> instruction that can (and does) prevent infinite exectuion. >>>>>>>>>> >>>>>>>>> >>>>>>>>> When we ask: >>>>>>>>> Does the call from DDD emulated by HHH to HHH(DDD) return? >>>>>>>> >>>>>>>> Why would anyone ask that? A question should make clear its topic. >>>>>>>> Instead one could ask whether HHH can fully emulate DDD if that is >>>>>>>> what one wants to know. Or one may think that HHH and DDD are so >>>>>>>> unimteresting that there is no point to ask anyting about them. >>>>>>> >>>>>>> A correct emulator can correctly any correct x86 instructions. >>>>>>> When it emulates non-halting code then itself does not halt. >>>>>> >>>>>> Not quite right but should be easy to fix. There should be a verb before "any", >>>>>> for example "execute". Of course there still is a probelm with the meaning >>>>>> "any correct x86 instructions". Intel may publish a new x86 processor that has >>>>>> instructios that the emulator cannot know but are nevertheless correct x86 >>>>>> instructions because Intel says so. In the second sentence "it" should be used >>>>>> istead of "itself". >>>>>> >>>>> >>>>> Intel has already done this and they call this x64. >>>>> A 1907 Model-T Ford cannot have upgrades and still >>>>> be a 1907 model-T Ford. Likewise for the x86 language. >>>> >>>> A new version of a 1907 Model-T Ford is possible and can have the same name >>>> except that the "1907" must be replaced as it refers to the year. That the >>>> "Model-T" is also replaced is a free chioce of Ford. >>>> >>>> Likewise Intel is free to call a new processor whatever they want to call it. >>>> >>> >>> The x86 language is a fixed constant. >> >> Where has Intel promised so? >> > > Backward compatibility requires it. > https://en.wikipedia.org/wiki/X86_assembly_language#:~:text=x86%20assembly%20language%20is%20the,was%20launched%20in%20April%201972. > That is about the assembly language, not about the machine instruction set. It does not say much about backwards compatibitlity and does not say that Intel has promised anything about that. Policy of backwards compatibilty does not mean that every x86 proscessor has exactly the same machine language as 8086. Later version have introduced new instructions and new processor modes and Intel is not prohibited from adding still more in future models. It only means that the meanings of the existing instructions are not changed when executed in existing modes. -- Mikko