Re: Incrementing volatiles?

[toddpw at ugcs dot caltech dot edu (Todd P. Whitesel)]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

>Sorry if I'm being dense... I just don't see any difference here: both are
>fetched, incremented and written back. And if it's "implementation defined",
>gcc is free to optimize this, isn't it?

Sort of. While the language standard that says "implementation defined" does
allow gcc to optimize it, many of the actual _users_ of gcc have a very clear
idea as to what 'volatile' means, and gcc needs to accomodate them.

The unwritten but de facto definition of volatile is that the activity on all
objects declared volatile (number of accesses, whether they are read or write,
the size of them, and the order of them) must remain the same independent of
the optimization level.

On "enough" systems this satisfies the condition that all I/O peripherals and
shared memory devices see the same events in the same time order for each
basic block in the program. Thus, most people's ideas of how to write device
drivers and multi-threaded code continue to work even when heavy optimization
is enabled.

It sounds to me that gcc is using an extremely conservative (but also very
safe, since handling of volatile is in principle very difficult to test!!)
implementation of volatile. I would strongly recommend leaving it the way
it is until a truly serious effort can be made to improve optimization of
volatile objects -- including exhaustive simulation of the target processors
to ensure that the relevant visible 'bus cycles' do not change when
optimization is enabled. Since the sim/ directory would be the first place
tapped for simulator technology, more targets implemented in there would be
A Good Thing.

Todd Whitesel
toddpw @ ugcs.caltech.edu