This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Incrementing volatiles?
- To: carlo at runaway dot xs4all dot nl, egcs at cygnus dot com
- Subject: Re: Incrementing volatiles?
- From: mrs at wrs dot com (Mike Stump)
- Date: Fri, 17 Jul 1998 05:18:31 -0700
> From: Carlo Wood <carlo@runaway.xs4all.nl>
> Date: Thu, 16 Jul 1998 01:43:20 +0200 (CEST)
> Can someone explain to me what exactly the definition
> of 'volatile' is? :)
Sure, what part was unclear? While there is some hair surrounding
volatile, I think it is fairly straight forward.
The basics: There is an implementation defined observation point of
the abstract machine that implements the required semantics of a
conforming program. Volatile is the way to `see' what is going on
with the machine.
>From a C++ working paper:
1 The semantic descriptions in this International Standard define a
parameterized nondeterministic abstract machine. This International
Standard places no requirement on the structure of conforming
implementations. In particular, they need not copy or emulate the
structure of the abstract machine. Rather, conforming implementations
are required to emulate (only) the observable behavior of the abstract
machine as explained below.3) |
__________________________
3) This provision is sometimes called the as-if rule, because an
implementation is free to disregard any requirement of the Standard as
long as the result is as if the requirement had been obeyed, as far
as can be determined from the observable behavior of the program.
6 The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions.4)
That's about it. There are more details, some of them are
obvious:
volatile int a; a = 1;
represents a `write', whereas
b = a;
represents a read (of a). Not as obvious are things like, if I have
two CPUs can I do s=++i; where i is a shared volatile between the two
CPUs, can I expect this to work? The answer is usually no. I say
usually, because a port maintainer is free to require that it work,
and free to ensure it does work, extending the compiler as necesary.
Though, the program that relies upon such a guarantee by a port, isn't
strictly speaking, portable.