🚀 go-pugleaf

X-Original-Date: 5 Jan 1996 10:40:05 +0100

Robert C. Martin (rmartin@oma.com) wrote:

|> In article <4c9740$27n@netlab.cs.rpi.edu> Srinivas Vobilisetti
|> <srv@cs.wayne.edu> writes:

|>    Nowhere i could find exact meaning of the specifier volatile.

|> Consider the following piece of code:

|> int n;
|> for (int i=0; i<99; i++)
|>   n=0;

|> A good optimising compiler should rewrite this as:

|> int n=0;
|> int i=100;

|> {That's right, if you want to delay for 100 micro seconds, the above
|> is not a portable approach.}

|> The use of the keyword volatile prevents the compiler from optimising
|> the reads and writes to a variable.  

|> volatile int n;
|> for (int i=0; i<99; i++)
|>   n=0;

|> Will cause zero to be written into the variable n 100 times. 
|> {Note, the compiler may be smart enough to do this without using the
|> variable i!}.

|> volatile int n;
|> for (volatile int i=0; i<99; i++)
|>   n=0;

|> Will cause zero to be written into the variable n 100 times.  It will
|> also cause the variable i to be incremented inbetween writes to n, and
|> will read i to test it for 99 each time through the loop.

Note, of course, that the exact meaning of operator ++ on a volatile
object is somewhat open to discussion.  For example, on a machine with a
hardware increment instruction, the compiler might increment `i' in
memory, *THEN* read it into a register, decrement the value and use it.
This may result in the value being read twice.

If the object in question is a normal memory object, and you are not
concerned with asynchronous events (signals, asynchronous thread
changes), this is probably not a problem.  If the object in question is
a memory mapped IO port, where a read has a side effect, this may be a
disaster.

As a general rule, the only things I would try to do with a volatile
object are to read them and write them directly, and not in the same
expression.  If I really had to increment a volatile int, I would
generally use three statements: tmp = i ; tmp ++ ; i = tmp ;.  (Of
course, since anything like this will be unportable by definition, I
would read the compiler documentation to see exactly how the compiler
treated volatile.)

|> Generally, this is used when certain memory registers have side
|> effects.  e.g.

|> int * volatile tty = 0x100;  // 0x100 is the addr of the tty device.
                        ^^^^^

This shouldn't work without an explicit cast, should it?

|> *tty = 'h'; // prints a 'c' on the tty;

|> void PrintMessage(char *s)
|> {
|>   for(; *s; s++) *tty = *s; // prints the string on the tty.
|> }

|> You can also use volatile if you want to create stupid delays as in
|> the first example.

Except that the length of the delay would still be undefined, since the
compiler can insert any additional code it likes into the loop.

On point concerning volatile that I have not seen made is the fact that
the C/C++ concept of volatile is orthogonal to atomicity of access.
Declaring an object volatile is *NOT* sufficient with regards to
asynchronous events; the object must still be of a type for which the
compiler will generate atomic accesses.  In general, char, short, and
int are safe, although there are exceptions.  (On 8 bit machines,
generally only char will be safe, and on the TI 9900 (and probably some
word addressed machines), int will be safe, but not char.)

In portable code, all you can count on is that at least one integral
type will be safe; that type is defined by a typedef to sig_atomic_t in
signal.h.  So in practice, there is almost nothing portable that you can
do in the presence of asynchronous events.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]