Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: A different view of volatile Message-ID: <4548@ihlpf.ATT.COM> Date: 27 Apr 88 00:37:01 GMT References: <13074@brl-adm.ARPA> <2003@rtech.UUCP> <7996@pur-ee.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 55 In article <7996@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: >Why not make use of this SAFE, prior-art, compiler hint? Currently, a C >compiler is correct iff it treats ALL non-register variables as volatile >(unless flow analysis can prove that the object address is never taken: >i.e., unless flow analysis can prove that it would have been safe to place >the variable in a register :-). I don't like this for a number of reasons. If a compiler assumes that all variables are volatile unless otherwise stated (such as by a register declaration), then I do not think that it is possible to do *ANY* type of optimization involving those variables. Even simple peephole optimizations such as 'a=b;a=b' cannot be legally optimized out, and 'x=2*y' and 'x=y+y' can yield two different results. What kind of optimization (or non-optimization code generation, for that matter) is legal and what is illegal?? Most of the semantics of C become ill-defined at best, if it has to use volatile variables. This is my main problem with using 'volatile' as it is defined now. Suppose a variable 'i' is declared 'volatile' because every time the memory location is referenced its' value is automatically incremented. What does '++i' or 'i <<= 1' mean? In these examples, is the memory location for i referenced once or twice? Since this is *implementation-dependent* (it is not addressed in the Standard as far as I could see), using these operations for any kind of portable application are meaningless. But try programming without them!! Try programming making the same assumptions that you want the compiler to make (ie, that all variables, unless otherwise stated, are volatile). Good luck! Unless you are *very* careful, you shouldn't use statements like tmp = a * b; c = tmp + a; since 'a' could have changed between the two assignments. (If you use this construct with the assumption that a,b,c,tmp are volatile and you really meant this as the outcome, this is still very hard to read/maintain.) Since you make assumptions about your environment when you program (it is probably impossible to program otherwise), why not let the compiler in on the secret? [I was also going to talk about how 'register' would now have too many meanings, but what I stated above is what I very strongly object to. This posting is long enough as it is.] Any variable which is 'volatile' automatically becomes non-portable and implementation-dependent. Therefore, assuming that all variables, unless otherwise stated, are volatile leads to machine-dependent unoptimizable code (given the current definition of volatile). This is not desirable and it defeats the purpose of a Standard. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_