volatile: a summary

[Steve Summit]

In article <11837 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> A perfect compiler would know as much as all its programmers combined,
> and could use whatever rules those programmers would use to detect
> `real volatility'.

In article <700 at fxgrp.UUCP> ljz%fx.com at ames.arc.nasa.gov (Lloyd Zusman) writes:
>But what if...

as have many others.

You people need to understand that Chris is being extremely
theoretical, to the point of pedagogy (not meant pejoratively),
here.  It took me several readings of several of his articles
(which I was quite willing to do, because Chris is a trustworthy
sort) to realize that he does, as usual, know what he is talking
about.  Chris _i_s _c_o_r_r_e_c_t when he says that "a perfect compiler
would not need volatile" but he is _n_o_t saying that such a
compiler would be reasonable.  He has stated several times that
an explicit "volatile" keyword is an eminently reasonable
pragmatic solution to a theoretically difficult problem, a
position with which I certainly agree.

Every article that suggests yet another funky architectural
scenario in which it would be next-to-impossible for the compiler
to reasonably "figure out" which variables should be volatile
overlooks one of the following:

     1.	There are ways other than a "volatile" keyword to tell
	a compiler which memory locations are volatile: a
	configuration file, for instance, not only solves the
	frequently suggested cross-compilation situations, but is
	also a better way of handling things like device
	registers: if location 0xABCD is a keyboard input buffer,
	it should really be volatile whether or not the
	programmer remembers to use (or knows about) the
	"volatile" keyword.

     2. If there are ambiguous or computationally undecidable
	cases, the compiler can always err conservatively by
	treating questionable variables as volatile (i.e. not
	optimizing away memory references).

Finally, the fact that (2) leads to unacceptable compromises like
"all system call return values are volatile," and the fact that
other cases are computationally horrendous, is why the "volatile"
keyword is useful.  Please don't post more "proofs" or
counterexamples; when you triumphantly say "So there!  No
compiler can reasonably get this one right without volatile!"
Chris is only going to say "Well, you're right; it could
theoretically get it right, but not reasonably, so that's why
we'll stick the `volatile' qualifier in."

My $0.02 worth: a command-line flag or pragma to effectively make
everything volatile would be very nice so that old programs can
be "correctly" (if inefficiently) compiled by the newer compilers
that make the kinds of optimizations that "volatile" is intended
to inhibit.

                                            Steve Summit
                                            scs at adam.pika.mit.edu