On Sat, 8 Jul 2006, Albert Cahalan wrote:
> >
> > 1. The volatile implementation of gcc is correct. The standard does not
> > talk about busses, not even about SMP.
>
> The standard need not. An implementation must deal
> with whatever odd hardware happens to be in use.
Not really.
The fact is, "volatile" simply doesn't inform the compiler enough about
what the effect of an access could be under various different situations.
So the compiler really has no choice. It has to balance the fact that the
standard requires it to do _something_ different, with the fact that
there's really not a lot of information that the user gave, apart from the
one bit of "it's volatile".
So the compiler really has no choice.
Btw, I think that the whole standard definition of "volatile" is pretty
weak and useless. The standard could be improved, and a way to improve the
definition of volatile would actually be to say something like
"volatile" implies that the access to that entity can alias with
any other access.
That's actually a lot simpler for a compiler writer (a C compiler already
has to know about the notion of data aliasing), and gives a lot more
useful (and strict) semantics to the whole concept.
So to look at the previous example of
extern int a;
extern int volatile b;
void testfn(void)
{
a++;
b++;
}
_my_ definition of "volatile" is actually totally unambiguous, and not
just simpler than the current standard, it is also stronger. It would make
it clearly invalid to read the value of "b" until the value of "a" has
been written, because (by my definition), "b" may actually alias the value
of "a", so you clearly cannot read "b" until "a" has been updated.
At the same time, there's no question that
addl $1,a
addl $1,b
is a clearly valid instruction sequence by my simpler definition of
volatile. The fact that "b" can alias with itself is a tautology, and is
true of normal variables too, so any combination of ops on one variable
(any variable always aliases _itself_) is by definition clearly always
valid on a "volatile" variable too, and thus a compiler that can do the
combination of "load + increment + store" on a normal variable should
always do so on a volatile one too.
In contrast, the current C standard definition of "volatile" is not only
cumbersome and inconvenient, it's also badly defined when it comes to
accesses to _other_ data, making it clearly less useful.
I personally think that my simpler definition of volatile is actually a
perfectly valid implementation of the current definition of volatile, and
I suggested it to some gcc people as a better way to handle "volatile"
inside gcc while still being standards-conforming (ie the "can alias
anything" thing is not just clearer and simpler, it's strictly a subset of
what the C standard allows, meaning that I think you can adopt my
definition _without_ breaking any old programs or standards).
But there really is no way to "fix" volatile. You will always invariably
need other things too (inline assembly with "lock" prefixes etc) to
actually create true lock primitives. The suggested "can alias anything"
semantics just clarify what it means, and thus make it less ambiguous. It
doesn't make it fundamentally more useful in general.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
