Path: utzoo!attcan!uunet!husc6!uwvax!vanvleck!uwmcsd1!ig!agate!ucbvax!decwrl!labrea!sri-unix!garth!smryan From: smryan@garth.UUCP (Steven Ryan) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Summary: On formally undecidable programs--part 2. Message-ID: <761@garth.UUCP> Date: 20 Jun 88 00:06:08 GMT References: <11837@mimsy.UUCP> <3811@pasteur.Berkeley.Edu> <580@wsccs.UUCP> <751@garth.UUCP> <12020@mimsy.UUCP> Reply-To: smryan@garth.UUCP (Steven Ryan) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 28 Church: Our Lady of Reluctant Software. In article <12020@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>>Chris is correct when he says that "a perfect compiler >>>would not need volatile" but he is not saying that such a >>>compiler would be reasonable. >I asserted not that it does exist, nor even that it could exist, but >only that one `perfect enough' to understand volatility ?????? > in a way that is `good enough' >(produces decent code even in the presence of its conservative erring) >*could* *be* *written* at some time in the future. Either it's perfect or it isn't. (Is `perfect enough' like `barely pregnant?') If it isn't perfect, and it can't be, then the original argument that volatile is never necessary is worthless. Obviously one could write a total recursive predicate that partitions what can be handled by a `perfect enough' compiler if conservative erring is accepted. What about what cannot be handled? Is it deemed not worthy of optimisation? Property X (X=volatile or anything else) cannot be determined for these outcasts. Either they are not optimised or a `perfect enough' compiler must be given hints (maybe we could create something like #hint or #pragma or create a new keyword like volatile). sm ryan Arrakis teaches the attitude of the knife: you cut that which is incomplete and say it is complete, because it ends here. -- Frank Herbet/Dune