This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile [was: GCC warnings for unused global variables]
Richard Henderson wrote:
On Wed, May 07, 2003 at 03:58:24PM -0700, Mike Stump wrote:
On Tuesday, May 6, 2003, at 09:03 PM, Alexandre Oliva wrote:
But then, so is a single instruction that loads, operates then stores,
right? The thing is that GCC doesn't ever give such instruction a
chance if the variable is volatile.
But, obviously, it should be made to.
No, that's not obvious at all.
My experience in previous discussions about volatile is that there
are a number of things which people consider obvious. And an
equal number of people who believe that they are not obvious.
It means that, the behaviour of the program is going to depend on
(1) Whether the source was written as "i++" or "i += 1" or "i = i + 1".
I think this would be astonishing to most C programmers.
(2) Whether the architecture supports load/op/store instructions at all.
This reduces portability of driver code across architectures.
Given the difficulty of validating driver code in the first
place, this is surely a big lose.
(3) Whether a particular revision of an architecture issues its
load/op/store bus cycles in the same manner. IIRC, 68000 vs
68020 is an example of this sort of change.
Code which uses volatile variables has limited portablity, especially
when used to control hardware. Depending on what volatile is used for,
it may or may not be possible to write code which works on different
versions of an architecture or on different architectures.
(4) GCC has never in its history issued load/op/store operations
for volatiles, and changing it now may well break previously
written drivers. This would, in effect, be an ABI change.
Since volatile is not precisely defined, it represents a hidden ABI.
There may be code which depends on the exact sequence of instructions
generated when acessing a volatile. Most programs would not be changed
if a load/op/store sequence of three instructions were replaced with a
single instruction, but some might be. Unfortunately, there is no way
to tell whether any particular program would be affected.
--
Michael Eager Eager Consulting eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077