volatile isn't necessary, but it's there

[Charley Wingate]

>Volatile is of use only with optimizing compilers; those that don't
>do some kind of data-flow analysis can ignore it.  More bluntly,
>it is intended to be used in cases where your compiler will do something
>other than what your program plainly asks it to do.

These statements only acquire truth because the default understanding of
what the compiler ought to do is very very conservative and tends to reflect
the most simple-minded way of understanding the code.

Without volatile, and allowing ...

>that it is possible to write a successful operating system
>without `volatile,' even on machines with memory-mapped IO

.... it is pretty difficult to formally specify what any action on an
non-local variable does, unless you essentially *know* whether the non-local
object is "volatile" or not.  If you're going to allow optimization on
non-local references, therefore, that information about volatility has to be
given to the compiler somehow.

This essentially establishes "volatile" as a semantic element, because its
effect is to "turn off" the semantic rules that optimizers rely upon.  As a
semantic component, it belongs in the language standard itself, not as a bag
on the side.

It appears that what people do now is, in effect, supply the volatility
information through compiler flags.  This, I feel, is undesirable because it
stores semantic information outside the code itself; without it, there is
nothing in the code to tell you that compiler options will change the
behavior of the program.  Some "volatile" construct IS necessary.

I'm not entirely convinced of the "confusion" argument either.  For one
thing, a person who can't understand the semantic implications of "volatile"
probably shouldn't be licensed to write the kind of programs that require it
in the first place!  :-) But more to the point, the only time it should
matter whether "volatile" is used is where it is actually necessary; if it
is used where it is unnecessary, the actual result had better be unaffected.
Perhaps a lot of people do not understand this implication, but I would
claim that this reflects the generally poor understanding of language
semantics in the profession.  People are able to just sit down and write
BASIC and FORTRAN programs without formal training largely because the
programs they write don't test the semantics of the language very far; the
time has to come, though, when language designers ought to be able to expect
something beyond a first-grade understanding of programming languages--
especially when we're talking about a language which is routinely used for
systems and multiprocess programming.

C. Wingate