Hi Bill,
On 5/18/07, Bill Davidsen <[email protected]> wrote:
Satyam Sharma wrote:
> *Unfortunately* (the trouble with C itself, is that a *committee* has made
> it into ... something ... that it should not have made it into) -- anyway,
> unfortunately C took it upon itself to solve a problem that it did not
> have (and does not even bring about) in the first place: and the
> half-hearted (or vague, call it what you will) attempt _then_ ends up
> being a problem -- by making people _feel_ as if they are doing things
> right, when that is probably not the case.
>
> [ And we've not even touched the issue of whether the _same_ compiler's
> implementation of volatile across archs/platforms is consistent. ]
It was a fun experience, where I first learned the modern equivalent of
Occam's Razor, Plauger's "Law of least astonishment," which compiler
writers regularly violate :-(
Well, here it was a case of the standard committee violating the principle
of solving a problem _where_ it exists in the first place. As far as volatile
is concerned, the _language_ itself had absolutely no problems that
needed fixing ...
Pardon, I was GE's representative to the original X3J11 committee, and
'volatile' was added to "codify existing practice" which is one of the
goals of a standard. The extension existed, in at least two forms, to
allow handling of memory mapped hardware. So the committee did not take
it upon itself, it was a part of the defined duty of the committee.
The intents was simple, clear, and limited, to tell the compiler that
every read of a variable in source code should result in a read, at that
point in the logic, and similar for writes. In other words, the code
should not be moved and should generate a real memory access every time.
People have tried to do many things with that limited concept since,
some with "clarification" and some with assuming the compiler knows when
to ignore volatile.
In fact I wish the standard just left this functionality entirely up to the
implementation.
After all, C (the _language_) does not mandate memory access
reordering / optimization by implementations so dumb compilers
(5.1.2.3:1) that do not do any are still conformant and hence
don't require the volatile extension (5.1.2.3:8). Implementations that
do perform optimization, otoh, _must_ then solve the possible problems
_themselves_ by providing an extension that allows the programmer
to turn it off (wherever necessary) to prevent those side-effects that the
implementation itself brought about by performing optimization in the
first place. That _compiler extension_ could then of course be called
anything (volatile, foo, bar, barrier, ...) and implemented in any way --
whatever is appropriate for that compiler [1].
[ Analogically, C (or any language) does not mandate the hardware
it runs on to reorder / optimize memory accesses. Those that do, must
clearly then also provide instructions like lfence/sfence/mfence as part
of their instruction set to solve potential issues that _their_ behaviour
brings about in the first place. How horribly wrong it would be for a
_language_ to try and go about solving this problem ... ]
So the way I see it, it's just a case of solving a problem _where_ it
exists in the first place.
Satyam
[1] Which begs the question, so if we wished (note past tense here)
to keep generic kernel code compiler-independent, what do we do in
situations where we want to disable _compiler optimizations_ temporarily
for some piece of code? => By defining macros / some API as part of
our codebase in implementation-specific headers that does whatever
needs to be done for _that_ compiler. => Which is precisely what we
have already and why I like/prefer that.
-
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]
