Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pacbell!att!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: Noalias trivia question Message-ID: <5104@ihlpf.ATT.COM> Date: 24 Jun 88 00:38:02 GMT References: <16244@brl-adm.ARPA> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 50 In article <16244@brl-adm.ARPA> dsill@nswc-oas.arpa (Dave Sill) writes: >Peter J Desnoyerswrites: >Yes, this is my point exactly. And it's very similar to what Chris >has been saying about `volatile'. I'd rather take a slight >performance hit to avoid a zillion modifiers like `volatile' and >`noalias' (who knows what will be next?) that can introduce subtle >bugs and complicate the language. I'm willing to wait until we have >compilers that can tell when aliasing is not possible or when >volatility is not possible, and optimize accordingly. I am also willing to take a slight performance hit for not adding 'noalias', but 'volatile' is a whole different story. The alternative to not adding volatile to the language is to assume that all variables are volatile unless they can be proven otherwise (such as non-static local variables which never have their address taken). This means most C statements cannot be optimized AT ALL (other than optimizations such as constant folding). >Herein lies the difference in our opinions. My philosophy is that >anything that can be done by the compiler to make the programmer's job >easier or anything that can be done better by the compiler should be >done by the compiler. I agree with you here. However, at this point in time, compilers can't determine volatility without being ultra-conservative. >Why require all programmers to be concerned >with aliasing/volatility/etc when, let's face it, they are so likely >to either not bother with it, or, if they do, to do it wrong? If you are using anything that is volatile (implicitly or explicitly) you have to worry about it and know what you are doing. >Should we pander to the least common denominator? No, but neither >should we introduce keywords aimed at the very small number of C >programmers that would actually use them correctly, especially when >their misuse by the masses would be inevitable. But if you don't add the keyword, you are pandering to the least common denominator. I would rather have C assume that all variables are not volatile unless otherwise stated (an assumption that most people make when writing code) and get the performance gains than to take the conservative view and have lots of non-conforming compilers around to produce production-quality code. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) You are in a maze of twisting little / / _ , __o ____ email paths, all different. / (_