Re: volatile keyword for C++ member functions
On Dec 30, 9:28 pm, Dave Rahardja
<drahardja.place...@sign.here.pobox.com> wrote:
On 2007-11-30 15:27:18 -0600, James Kanze <james.ka...@gmail.com> said:
But keep in mind that its original purpose was embedded
programming, where reading from a hardware register twice
could return two different values, both of which were
important. That, of course, has nothing to do with
multi-threaded programs.
At least on a Sparc, most compilers don't even support that much
with volatile. (I'm not up to date with how modern Intel
handles I/O, but the Sparc architecture specifications states
explicitly that you need additional membar instructions for it
to work.)
In my recent experience the volatile keyword is next to
useless on most compilers, embedded or not, if you want
something portable.
Almost by definition, anything involving volatile isn't
portable. There are a few exceptions where longjmp is
involved, but there are intentionally no useful semantics
defined by the standard for it. The *intent* is that the
compiler writers provide something that is useful in the context
targeted by that compiler. And thus, that counting on the exact
semantics not be portable.
It's important to realize that the initial motivation for
volatile was memory mapped IO, which, of course, will never be
portable anyway.
I find that today's microprocessor designs have introduced a
variety of contexts that must be synchronized in order to
achieve "true" visibility (caches, pipelines, multiple core
access to shared cache/RAM, etc).
Embedded microprocessors as well? I know that this is a problem
on general purpose computers, from the low level PC's on up, but
I would have thought that the low end of the embedded processor
range wouldn't have such sofistication.
On single-core PowerPC, for example, each access to a volatile
variable must be followed by a data pipeline flush in order
for it to "take" to hardware.
The Power PC is a bit more than what I was thinking of. When I
last did such work, the predominant processor was the Intel
8051: 128 bytes RAM, 2K ROM. And a store instruction that went
direct to memory (and didn't "terminate" so that the next
instruction could begin until the write was finished).
I've given up on the use of volalite and have defined a
compiler- and platform-specific library interface instead. It
makes the main code much easier to port.
I think you'd want to do this anyway. Where I would imagine
(hope?) that volatile would be useful is in the
platform-specific library---as an alternative, in certain cases,
to inline assembler (or writing the entire function in
assembler).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34