the "volatile" keyword

Perry E. Metzger perry at piermont.com
Fri Nov 8 01:07:51 EST 2002


Don Davis writes:

   * the c99 standard and its predecessors don't
     at all intend "volatile" to mean what we naively
     think it means.  specifically, in the hands of a
     high-end compiler developer, the spec's statement:
        "any expression referring to [a volatile]
         object shall be evaluated strictly according
         to the rules of the abstract machine"
     is really talking about what the compiler can
     infer about the program's intended semantics.
     a c99-compliant compiler _can_ legitimately
     remove a volatile access, as long as the compiler
     can deduce that the removal won't affect the
     "program's result." 

Sorry, but that is really not correct at all.

"volatile" exists because there are times when you absolutely need to
know that the compiler will not alter your intent. A typical example
is in touching a device register in a device driver. You may very well
need to write a certain set of values out to a particular memory
location in a particular order and not have them optimized away or
reorganized. It may be vitally important to access register 2 and then
register 1, or to write multiple values out to register 4 before
touching register 3, or what have you.

In a driver or in a situation like this you really do mean "write a
one there and then write a ten there and never mind that you think you
can optimize away writing the one there."  "volatile" means that the
memory location has side effects and that you CANNOT deduce the result
of the operations and thus are required to not touch the sequence at
all. The spec specifically states that you may NOT remove or reorder
sequence points if "volatile" is in use.

That is why "volatile" exists. It means "do NOT reorder or eliminate
access to these memory locations on pain of death". The intent of the
spec is precisely what I've said, and I'll happily quote chapter and
verse to prove it.

There are several similar misconceptions about the "volatile" keyword
that have been propagated in recent messages.

Claims that "volatile" does not guarantee a safeguard against such
optimizations are specious. That is exactly why "volatile" was
introduced, and if, for example, gcc did not honor it, the machine I
am typing at right now would not work because the device drivers would
not work. Any optimizing compiler that people write device drivers in
practically *has* to support "volatile" or it won't work for that
purpose. (In the days before "volatile" you needed vile tricks to
assure your intent was followed, or you needed to not optimize driver
code, or both.)

Some have claimed "volatile is not a mandatory part of C". Well, it is
certainly mandatory in the C standards I have at hand. C99 makes it
abundantly clear that you have to do it and do it correctly.

Some have claimed "you can't know that the compiler writer implemented
volatile correctly so you need a #pragma". Well, that doesn't actually
help you. If they haven't implemented "volatile" right, why should
they implement the pragma correctly? We already have a way of
indicating "do not reorder or eliminate this code" which is in
existing standards -- if it doesn't work, that's a bug in your
compiler, and it is better to get the bug fixed than to ask for
another feature to be added that might also be buggy and which is not
part of the standard.

So in short, yes, "volatile" might be implemented in a buggy way by
your compiler (which you should certainly test for if it is important
to you!) but if your compiler is in fact properly implemented and
standards compliant, "volatile" is the way to accomplish what you are
trying to accomplish here.


-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list