Re: volatile [was: GCC warnings for unused global variables]

[Michael Eager <eager at eagercon dot com>]

Fergus Henderson wrote:
> 
> On 01-May-2003, Richard Henderson <rth@redhat.com> wrote:
> > On Thu, May 01, 2003 at 08:47:03PM -0700, Geoff Keating wrote:
> > > For instance, at program startup (in this case) the abstract machine
> > > says the string contains a particular value, and how can it do that if
> > > it is optimized away?
> >
> > Ok, I'll play your game.  By the as-if rule, it *does*
> > have that value.  Any time the program cares to check
> > that'll be true.
> 
> The "as-if" rule (C99 5.1.2.3, C++98 1.9) only applies to non-volatile
> objects.  The part of C and C++ standards which defines the "as-if"
> rule specifically requires implementations to not optimize away accesses
> to volatile variables (C99 5.1.2.3, C++98 1.9 paragraphs 1 and 7), and
> to ensure that "At sequence points, volatile objects are stable in the
> sense that previous evaluations/accesses are complete..." (C99 5.1.2.3
> paragraph 5, C++98 1.9 paragraph 11).
> 
> In general the wording of the C and C++ standards about the semantics of
> volatile is pretty vague (e.g. what constitutes "access" to a volatile
> object is implementation-defined) and so there may perhaps be room for a
> weasely interpretation which allows what you seem to want.  But performing
> such an optimization would be a clear violation of the intent and spirit
> of these standards with respect to volatile.  The purpose of volatile is
> to precisely to suppress optimizations like these, and any implementation
> which optimizes away volatile variables is at best greatly lacking in
> quality-of-implementation, if not in outright violation of the standard.

When I was on the C++ Standards Committee, I submitted a proposal which
was intended to make volatile well defined and explicit, rather than use the 
vague definition inherited from C.  Unfortunately, the proposal was not
adopted.  A large part of the committee felt that volatile was an obscure
feature which did not need clarification.  The small part of the committee 
which thought that volatile was important had the opinion that it would be
impossible (or at least very difficult) to define it precisely, although it 
appeared that we all agreed on the same correct behavior for volatile.

Volatile is usually described in terms of an outside observer, about which the
compiler cannot know anything, which can detect or make changes to a volatile 
variable at any arbitrary time.

It can also be described in more practical terms:
   -- each read or write of a volatile must be exactly as specified by the
      abstract machine
   -- the ordering and number of reads or writes to a volatile must be 
      exactly as specified

One behavior which was difficult to define precisely was when a volatile was
either smaller or larger than can be read or written in a single memory access. 
I think that there are also a number of other behaviors involving volatile
variables which could be tedious to define unambiguously.  

An unreferenced volatile variable has no reads or writes which need to be
represented.  But its existence (or absence) and value may be informative to 
that unknown outside observer, so I believe that a compiler should not remove 
it.  Or, by extension, complain about it's existence.  


-- 
Michael Eager    Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077