This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Incrementing volatiles?


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]