A different view of volatile

[00704a-Liber]

In article <7996 at pur-ee.UUCP> hankd at 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."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah