const, volatile, etc

[Ray Dunn]

In article <319 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>  [long argument against "volatile]
>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 &...).

Unfortunately, the whole foundation of your argument is incorrect.  All
variables in tradional 'C' are *non-volatile*.

Nowhere is there any guarantee that each and every variable reference made
in a 'C' source will translate to a memory reference in the run code.

That is what "volatile" gives you.

> [continued long argument totally confusing "volatile" with
>  *performance* issues and the use of "register"]

There is no relationship between "volatile" and "register", except that
conceptually, "volatile" variables can *NOT* be of type register and cannot
be arbitrarily *kept* in a register in the compiled code.  In addition to
the performance issue, "register" implies the exact opposite of "volatile".

>Arguments for volatile, as opposed to register, are essentially:
>
>    [1] you cannot trust programmers to be competent and understand
>    what they are writing, or at least not enough to place appropriate
>    register declarations; in that case an automatic optimizer will
>    possibly improve things, even if it does a purely static analysis.

Volatile is not *just* needed as an adjunct to optimizing compilers.

Volatile is needed in *all* cases when the programmer wishes to convey to
the compiler that a variable has environmental constraints normally not the
concern of the compiler.

It is in fact only luck that most traditional compilers handle machine
specific volatile variables correctly when no optimization is called for,
and without the use of the "volatile" keyword.

>As to point [1], unfortunately you need damn competent programmers that
>understand a lot of the subtleties of their program to place volatile
>where it is needed, and only there, otherwise they will be inclined,
>for safety, to declare everything in sight to be volatile...

and produce "vapourware" I presume.... (:-)

The argument that programmers can be expected to be competent enough to
design the algorithms of the program, and analyse their code sufficiently to
be able to duplicate the effects of a good optimizizing pass, but that
somehow some esoteric higher level of understanding is required to be able
to place "volatile" appropriately, I find most unconvincing.

If the programmer does not understand which variables are referencing
"locations" which can side effect or be side effected by other software or
hardware, then should (s)he be let loose in that environment?

Classical examples of the need for "volatile" are when handling memory
mapped I/O, or inter-process signals.  In these cases, amongst many others,
we need to ensure that the compiler is not treating an I/O write or a signal
update as an intermediate value that does not *yet* need to be written into
the actual memory location.

Does the traditional definition of 'C' allow the programmer to be sure that
the compiler is treating these cases correctly?  Nope!
-- 
Ray Dunn.                      |   UUCP: ..!philabs!micomvax!ray
Philips Electronics Ltd.       |   TEL : (514) 744-8200   Ext: 2347
600 Dr Frederik Philips Blvd   |   FAX : (514) 744-6455
St Laurent. Quebec.  H4M 2S9   |   TLX : 05-824090