Deutsch English Français Italiano |
<v9hmfc$c71c$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!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: HHH maps its input to the behavior specified by it --- key error in all the proofs --- Mike --- basis Date: Wed, 14 Aug 2024 10:30:52 +0300 Organization: - Lines: 149 Message-ID: <v9hmfc$c71c$1@dont-email.me> References: <v8jh7m$30k55$1@dont-email.me> <dec62801011bc5bf0b9eb9a62c607cf407198609@i2pn2.org> <v99870$14mlk$1@dont-email.me> <0f8f134fe961ee00910cce1d7f05b632d7567c6c@i2pn2.org> <v9abfu$2nabt$1@dont-email.me> <86c21e8a63450bf8b0c32f4f17ba0b503a914fe0@i2pn2.org> <v9d01i$39tbd$2@dont-email.me> <2c853efb65c3d8e2d4ba1c484f7002c74c68d895@i2pn2.org> <v9d1v8$3a9pe$1@dont-email.me> <e614d6b981fd5fa6eefc84894a14448d4663e3c7@i2pn2.org> <v9da2d$3bth4$1@dont-email.me> <64ddeeaa3a55a9e410de599bd8df53d3644ee5a3@i2pn2.org> <v9de0o$3cjse$1@dont-email.me> <v9dela$3cjse$2@dont-email.me> <b7c45ea22cb83908c31d909b67f4921156be52e3@i2pn2.org> <v9dgvl$3d1an$1@dont-email.me> <d289636b1d244acaf00108f46df093a9fd5aa27c@i2pn2.org> <v9dk2j$3dp9h$1@dont-email.me> <8318f5969aa3074e542747fe6ba2916d7f599bde@i2pn2.org> <TyKdnc3hCNvmUyf7nZ2dnZfqn_udnZ2d@brightview.co.uk> <v9ekta$3necg$1@dont-email.me> <2f8c1b0943d03743fe9894937092bc2832e0a029@i2pn2.org> <v9fn50$3ta4u$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 14 Aug 2024 09:30:53 +0200 (CEST) Injection-Info: dont-email.me; posting-host="c3c24c5ffe79752ad72ef4cdb11b642f"; logging-data="400428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IdQPcXa0u6Ozyy4NJAVwg" User-Agent: Unison/2.2 Cancel-Lock: sha1:j8KkC74uirhwhE/tAw5PRzldOwA= Bytes: 8767 On 2024-08-13 13:30:08 +0000, olcott said: > On 8/13/2024 6:23 AM, Richard Damon wrote: >> On 8/12/24 11:45 PM, olcott wrote: >>> On 8/12/2024 10:09 PM, Mike Terry wrote: >>>> On 12/08/2024 22:13, Richard Damon wrote: >>>>> On 8/12/24 2:25 PM, olcott wrote: >>>>>> On 8/12/2024 1:16 PM, Richard Damon wrote: >>>>>>> On 8/12/24 1:32 PM, olcott wrote: >>>>>>>> On 8/12/2024 12:12 PM, Richard Damon wrote: >>>>>>>>> YOU don't understand the rules of the x86 code, or don't care if you >>>>>>>>> are wrong, as NOTHING in the x86 language allows the leaving of the >>>>>>>>> direct exectuion thread and into showing the code the simulator being >>>>>>>>> simulated is simulating. The ONLY correct answer is showing it doing >>>>>>>>> the simulating. >>>>>>>>> >>>>>>>> >>>>>>>> I showed the first four lines of this code >>>>>>>> highlighted in red and you ignored it. >>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>> >>>>> First a few comments about this file. >>>>> >>>>> It has clearlly changed over time without notice, you said you added >>>>> highlighting, but it also has had content changes. >>>>> >>>>> It really needs to be date-stamped and version controlled. I can not >>>>> say if the copy I look at today is the same as I looked at the other >>>>> day. >>>>> >>>>> Second, it is NOT the trace you keep on claiming but is the trace that >>>>> x86UTM makes of running main, with the trace that the levels of HHH do >>>>> inserted (WITHOUT COMMENT) into the listing, making the trace that HHH >>>>> generats hard to find. >>>>> >>>>> The length of the wrong trace starts on page 38, so there are only >>>>> about 160 pages of trace (the rest is an assembly listing of the >>>>> program, useful to understand the trace, but not part of the trace >>>>> itself) and there are only 1 to 2 lines from HHH per page, so a trace >>>>> of just what HHH does would be only about 200-300 LINES long, not 200 >>>>> pages, and not beyond what many people can handle, especially when you >>>>> remove the cruft of having to wade through all the other junk that >>>>> isn't the trace that HHH makes. >>>>> >>>>> There are also clearly functions that are not even correctly listed in >>>>> the assembly listings, nor traced, that seem to be hooks to make OS >>>>> calls. That isn't totally unreasonable, but not clearly marked as such. >>>>> >>>>> >>>>>>> >>>>>>> No, you ignored my comments. >>>>>>> >>>>>>> First, that isn't a trace generated by HHH emulating DDD, but by x86UTM >>>>>>> emulating HHH, so your claim is just a type error. >>>>>>> >>>>>>> Then when I look at this emulation, we see that HHH *ONLY* emulates >>>>>>> those first 4 instructions of HHH and no more, >>>>>> >>>>>> That is counter factual. >>>>> >>>>> Looking closer, I may have gotten confused by the changing file by the >>>>> same name >>>>> >>>>> I do see the simulation continuing into HHH, but ... >>>>> >>>>> One thing I do note is that the trace sees conditional jump >>>>> instructions in the trace, but your "rule" is that there can be no >>>>> conditional instructions see in the full loop, so something is wrong. >>>>> >>>>> One instruction I see is: >>>>> Page 79, simulated the JNZ 00001335 at address 000012f8 >>>>> Why wasn't this counted as a conditional instruction in the trace? >>>>> (That means the recursion isn't unconditional) >>>> >>>> PO's rule is that there must be no conditional branch instructions >>>> *WITHIN DDD*. Conditional branch instructions in HHH are simulated, >>>> and with suitable compilation options [I think it is the >>>> TRACE_USER_CODE_ONLY pre-processing symbol that needs to be undefined] >>>> those instructions will also be LOGGED. Well, you're seeing the result >>>> of that on page 79 of the PDF file. >>>> >>>> Distinction between what is LOGGED (by x86utm.exe), and what goes into >>>> the global trace table examined by HHH: The former is an x86utm >>>> ("supervisor?") concept. The latter is HHH application logic - HHH >>>> implements the tests for "non-halting" patterns, and only needs to >>>> capture trace entries needed to apply its rules. For example, since >>>> the rules explicitly ignore trace entries from HHH, HHH doesn't need to >>>> capture them. You can see those trace entries in the x86utm LOG, which >>>> is why the log is the way to go, when working out what's going on and >>>> why. >>>> >>>> Just to be 100% clear for PO's benefit, when I say HHH "only needs to >>>> capture trace entries needed to apply its rules" I am not suggesting >>>> those rules are correct - just that from a coding perspective, there's >>>> no point in a program capturing data that is irrelevent for it's later >>>> processing. As an example here, PO adds trace entries to his global >>>> trace table which are of no interest to any of his rules! Really, he >>>> is only interested in branches, calls, and the likes, but he captures >>>> everything DDD does like "mov ebp,esp" or whatever which his rules all >>>> ignore... Not an issue in practice because his trace captures [given >>>> other filtering] are tiny. Might become important for capacity reasons >>>> if PO wanted to include HHH entries, but he doesn't. >>>> >>>> Now, anyone thinking sensibly at this point is going to ask *WHY* does >>>> PO's rule >>>> *exclude conditional branches within HHH* when they are obviously >>>> critical to halting? PO will never explain that. >>> >>> *I have always explained that and everyone ignores my explanation* >>> >>> On 8/2/2024 11:32 PM, Jeff Barnett wrote: >>> > ...In some formulations, there are specific states >>> > defined as "halting states" and the machine only >>> > halts if either the start state is a halt state... >>> >>> > ...these and many other definitions all have >>> > equivalent computing prowess... >>> >>> Now I have the same basis that I have repeated many >>> times that cannot be so easily rejected out-of-hand. >>> >>> void DDD() >>> { >>> HHH(DDD); >>> return; >>> } >>> >>> *DDD correctly emulated by HHH cannot possibly reach its* >>> *own "return" instruction final halt state, thus never halts* >>> >> >> Which is only correct if HHH actuallly does a complete and correct >> emulation, or the behavior DDD (but not the emulation of DDD by HHH) >> will reach that return. >> > > A complete emulation of a non-terminating input has always > been a contradiction in terms. > > HHH correctly predicts that a correct and unlimited emulation > of DDD by HHH cannot possibly reach its own "return" instruction > final halt state. That is not a meaningful prediction because a complete and unlimited emulation of DDD by HHH never happens. -- Mikko