volatile

[Chris Torek]

>In article <11566 at mimsy.UUCP> I wrote:
>>There are pragmatic reasons not to find all cases of [*] volatility (it
>>may take too long on a given machine), but it can be done.  When it can
>>be done, it should be done.

[* I left a word out here: `potential'.  I did not leave it out of
earlier discussion.]

In article <227 at proxftl.UUCP> bill at proxftl.UUCP (T. William Wells) writes:
>The reasons are NOT pragmatic, they are theoretical.  It is NOT
>possible to find all cases of volatility in a program.

I know that; and you deleted the part of my article that mentioned it.
There are indeed cases in which volatility cannot be determined (as
there are cases where aliasing cannot be determined).  In such cases,
the compiler can simply be conservative and assume that the variable
may be volatile or aliased.

In the limit, the compiler may simply assume that all variables are
volatile and aliased; it will then act much like the C compilers we
have been using on Unix systems.  It may produce suboptimal code,
but it will produce correct code, and it does not need a `volatile'
keyword.

This does not mean that `volatile' is bad.  It merely means that
I feel that a compiler that, given something like the following,
prints a warning that `rkaddr' should be declared `volatile' (since
the proposed C has the keyword) is superiour to one that does not.

	struct rkdevice *rkaddr = (struct rkdevice *)0777440;

(Clearly this requires knowledge of the machine internals, and
may have to be enabled by switches, e.g.  It remains useful.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris