volatile

[Doug Gwyn]

In article <319 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>My extreme hostility to "volatile" (and, as I had forgot to mention,
>making all standard procs names "reserved words")

In a freestanding implementation of ANSI C, the standard library functions
are NOT reserved.  In a hosted implementation they are reserved for very
good reasons, including several having nothing to do with optimization.

>volatile (and "reserved word" procs) instead try to make respectable the idea
>that a complex expensive optimizer will give you substantially better
>performance than a little ingenuity.

They don't HAVE to "try to make the idea respectable", since it happens
to be true.

>First of all, in a sense, volatile and register exclude each other; in
>traditional C all variables are volatile save for those declared to be
>register (and this explains why there is a restriction on &...).

Traditional C simply had nothing to say about whether ordinary variables,
or register ones for that matter, were effectively volatile.  This is one
of the things X3J11 had to decide.  In making the decision, they realized
that the other choice also needed support, thus addition of "volatile".

>People who really care about speed know that register is perfectly
>adequate, IF USED COMPETENTLY, given a compiler that does a
>straightforward but COMPETENT generation job (most tuned PCCs), to make
>non benchmark programs run fast.

Most highly-optimizing compilers pretty much ignore programmer-supplied
"register" specifiers.

Because C has always had the rule that the address-of operator cannot
be applied to a register variable, "register" CANNOT suffice in place
of volatile/nonvolatile.

>Arguments for volatile, as opposed to register, are essentially:
>    [1] you cannot trust programmers to be competent and understand
>    what they are writing, ...

Since proper use of "volatile" definitely DOES require programmer
understanding, you're imagining things if you think that anyone
on X3J11 supported that argument.  In fact, "trust the programmer"
was one of our mottos.

>    [2] you want people to pay a lot of money for your latest
>    optimizing compiler technology for C, and you want it to be blessed
>    by dpANS, so you can say of other compilers "they do not
>    have/implement volatile" without people questioning whether it is
>    useful at all (it's in the standard!).

It happens that I have no financial interest in the production of C
compilers, yet I support "volatile", which (contrary to your claims)
is a way to AVOID trouble with optimization.  Optimization is happening
anyway; it is by no means caused by the existence of "volatile".

Griff would have been sunk in his signal handler example without
"volatile".

>As to point [1], ...
>As to point [2], ...

What is the point of setting up straw men then knocking them down?
Since your points [1] and [2] are the product of your own fevered
imagination, you're wasting our time discussing them.

>instead of the obviously proper better structured and efficient C way

Way to go -- you took a vectorizable loop and turned it into an
unvectorizable one.  What an efficiency improvement that is.

>you never make a program wrong by declaring a variable register,

Wrong!

>but it may be wrong if you fail to place volatile where it is needed.

If it needs the "volatile" to be correct, then it is ALREADY crucially
dependent on features that ARE NOT GUARANTEED and never have been.

> (usually good peephole optimization is enough)

The marketplace apparently does not agree with you.

> volatile is a loss; it is a ... new and difficult concept

Not at all.  The concept has long been familiar to C programmers who
need to worry about it, but there previously hadn't been a good solution
to the problem.  Simply stated, it is "if you need to be sure that a
variable is accessed exactly at the times that it would appear to be,
judging by the C source code, then declare it using volatile".

>when I first studied C many years ago, I was
>really struck by the cleverness of having a register storage class, its
>careful definition, the obvious advantage of having the programmer
>select the few crucial variables to cache, obviating the need for a
>complex and large optimizer to do the same job, only worse.

Optimizer technology has come a long way since the invention of C.
"register" was an aid to optimization technology of the 1970s,
"noalias" was an aid to optimization technology of the 1980s (but
alas we don't have it).  "volatile" does not aid optimization, but
it does make it more tolerable.

I should point out that X3J11 has several active members who are
much better able to evaluate optimization technology than you or I.
The committee was therefore able to make informed decisions on
these matters, and I suggest that you defer to their judgement.