Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!osu-cis!att!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: volatile Message-ID: <4346@ihlpf.ATT.COM> Date: 8 Apr 88 19:23:51 GMT References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <18686@think.UUCP> <4217@ihlpf.ATT.COM> <10914@mimsy.UUCP> <150@ghostwheel.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 48 In article <150@ghostwheel.UUCP> ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes: |Many people have claimed that "volatile" is necessary for a variety of |applications. Every one of which has been successfully written at one |time or another. Does this mean that all these signal handlers, |interrupt handlers, etc. are written in assembly or some other language? |I suppose it also means that those which are written in K&R C are |incorrect... Uh... completely unoptimizable. (To -O or not to -O...) No, what this means is that in the future, when we have highly optimizing compilers and highly efficient hardware (such as caches,etc.), that this code may break. In order to do certain types of optimizations, certain assumptions have to be made. For example, if I know that a certain variable has no aliases, then in the implementation I can keep it's value in a cache (which is faster) without having to update the actual memory location it is suppose to be stored at. As things stand now, these assumptions are made on a compiler-by-compiler basis. |In fact, why is it assumed that silent optimaztion of poorly (or, |perhaps, correctly) written code is desirable? Just because a compiler |can be made smart enough to move a loop invariant out of a loop does not |mean that it is a good idea. It makes more sense to just provide the |programmer with a warning. If the code is incorrect, the programmer |learns something valuable. If it is correct, the programmer may save |himself (or herself) a frustrating bout of debugging. |Optimizers should not do optimazations which can be expressed in the |source language itself. Not all optimizations can be 'hand-coded'. For those which can be hand-coded, however, I would still rather have the compiler do all the work for me. Hand-optimizing takes a lot of time and usually turns well-wriiten readable code into something that can be entered in the Obfuscated C Contest :-). |However, if they recognize a possibly |poor construct, they should warn the programmer. (At least until |automatic code generators can be made better programmers than your |typical Unix wizard.) Lint, not C, is suppose to warn the programmer of possibly poor constructs. Code generators are not better designers (which is what you should be using your typical Unix wizard for :-)), but they can be better implementers. :-) -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_