Here's a bit of what I remember (extracted from
neurons that haven't twitched in a VERY long
time) about the "volatile" keyword; it specifies
not simply what the compiler must do with data,
but what assumptions it is allowed to make
about data. The constraints on optimization are
inescapable but are an effect rather than a goal.
The source code for a (high level) program
is, formally, a specification for a series of
transformations to be made to various data.
The compiler is normally free to perform the
specified computations by any means and in any
locations it chooses. The compiler would ideally
be free to act as if the resultant program will
be the sole occupant of its address space with
no data changing for any reason except as the
result of operations performed on them by the
program in question, ie. a single-threaded and
perfectly synchronous world. Under these ideal
conditions it doesn't matter, strictly speaking,
where a given datum "is" because as long as the
specified computations are performed, who cares?
(The situation is, of course, not this
simple, but anyway...)
That perfect world doesn't really exist, though,
because programs do have to deal with data
that change ansynchronously; programs have
to manipulate hardware registers, coordinate
with interrupt service routines, manage DMA
buffers, synchonize with other threads, etc, etc.
The volatile keyword was introduced to give the
programmer a way of saying, "Hey! you're not
the only entity who cares about that thing over
there - it may change at any time, so don't make
any assumptions about it, and also be sure to
keep it up to date whenever you've officially
completed any manipulations of it."
IIRC, the C spec says that a specified change
to a given datum is supposed to be "complete"
a "sequence point" is reached which usually
corresponds in C to the semicolon which
terminates the corresponding statement. For a
given variable declared volatile, the compiler
is free to keep the results of intermediate
computations involving that datum anywhere it
likes, but must update the variable's "official"
location when it reaches the next sequence point.
This is where the constraints on the optimizer
come from; you've told it that it's still allowed
to optimize the code for any given statement or
group of statements, but all manipulations of
volatile data must play strictly by the rules
at the corresponding sequence points.
This rules out register-resident variable in
most cases.
[ Ooops - late for a meeting - I'll post this
in half-baked form rather than keep it... ]
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
