volatile: a summary
Daniel R. Levy
levy at ttrdc.UUCP
Fri Jun 10 08:20:47 AEST 1988
In article <11837 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
# READ THE WHOLE THING BEFORE YOU FLAME.
# Given that the keyword is not absolutely necessary,
# is it of any use?
#
# Yes. If the keyword exists, compilers are free to assume that any
# variable not tagged by the keyword is truly not volatile. This is a
# very easy way to discover which variables should be considered to have
# the attribute, and, knowing which variables are not volatile, the
# compiler can make a number of optimisations that might otherwise be
# unsafe. This is not without its cost: With such a compiler, the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# programmer must correctly label any variables which do have the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# volatility attribute. But because the scheme is simple, compilers that
^^^^^^^^^^^^^^^^^^^^^
# use it can be faster than, and need not be as complex as, compilers
# that attempt to find `real volatility' with less help from the
# programmer. Being less complex, such compilers are more likely to
# be correct; being faster, they are more pleasant to use.
And therein lies a problem. This could easily break old, "volatile-less"
code. I would certainly want such a compiler to have some way of turning
off this behavior while still keeping the "obviously" safe optimizations
(however the term "obviously" might be defined depending on the smarts in
the compiler in question). A compiler which could NOT turn off this
"volatile"-assuming optimization would make me nervous whenever reuse of
old code is concerned.
For argument's sake, is this something which could potentially be specified
in the proposed ANSI C specification? Does the spec have any notion of
the existence of "compiler flags," i.e., furnishing information not in the
source code itself to the compiler at compile time?
--
|------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| AT&T Data Systems Group | Weinberg's Principle: An expert is a
| Skokie, Illinois | person who avoids the small errors while
|-----Path: att!ttbcad!levy-----| sweeping on to the grand fallacy.
More information about the Comp.lang.c
mailing list