volatile: a summary

[Dave Sill]

Peter J Desnoyers <peter%athena.mit.edu at BRL.ARPA> writes:
>How do programmers decide questions that are not decidable by the
>compiler? They don't. They avoid them.

No they don't.  They decide them by making assumptions or using
information that is not available to the compiler.  I say we should
give the compiler the same information so it can potentially do the
same thing the programmer would do.  Just how we do this is not clear.
In the case of volatility it appears that the best solution for now is
the `volatile' storage class.  In the case of aliasing we aren't able
to agree on a solution, yet.  My fear is that we'll just keep adding
new storage classes or other keywords as they are needed, making the
language more and more complicated, rather than trying to develop a
more general solution that fits within the current language.

>Compilers cannot avoid any
>construct that is legal in the language, while programmers can and do
>in the name of decent programming style. Fortran programmers
>routinely use vector operations that require non-aliased arguments.
>Whether or not the arguments are aliased is not decidable, but the
>programs work.

If the programs work, it's because the assumption that the arguments
are non-aliased is true.  In general, this is not an accident, but is
a result of the programmer being aware of the aliasing restriction.

Although the aliasing problem in general is undecidable, in reality
this is not a problem.  In Fortran code using such vector operations
the arguments are usually hard-coded arrays and there is no
possibility of overlap.  In C, things are a little more complicated,
particularly due to the use of pointers.  It's not always obvious by
looking at the code whether aliasing occurs or not.  Should we let
the programmer say explicitly that aliasing is not occurring (based on
his assumptions), or should we make him tell the compiler what those
assumptions are so they can be verified?

=========
The opinions expressed above are mine.

"A well-written program is its own heaven;
 a poorly written program its own hell."
					-- The Tao of Programming