volatile

[Chris Torek]

>In article <11709 at mimsy.UUCP> I claimed that
>>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 last point---that C without `volatile' has been used for systems
work---seems to have been ignored by those who claim that volatile is
necessary.  (Note that I claim only that it is unnecessary, not that it
is bad.)

In article <5590 at bloom-beacon.MIT.EDU> peter at athena.mit.edu
(Peter J Desnoyers) writes:
>C compilers on most Unix systems do not assume that all variables are
>volatile,

True enough: register variables are not considered volatile.

>and they certainly do not assume that all memory is volatile.

Let us try an experiment:

	f() {
		register int i, *ip;
		i = *ip;
		i = *ip;
	}

produces

	movl	(r10),r11	# i = *ip
	movl	(r10),r11	# i = *ip

That sure looks like the code I would expect from

	volatile int *ip;

and not like the code I might expect without it (since `i' is unused, I
would be unsurprised to find the body of f() elided altogether).

(In fact, unless the `-i' flag is used, the 4BSD optimiser /lib/c2 can
make some changes to memory references that can cause trouble, so this
is somewhat weak.)

>In the first case, the program results would be at best completely
>undefined, and in the second case code generation would be impossible,
>as there would be no guarantee that the processor would ever get to
>see it before it was modified.

This does not follow.  The virtual machine semantics provided in the
absence of volatile declarations are still there in the presence of
such declarations; volatile simply adds a constraint, or a set of
constraints.  The precise constraints added are machine-dependent,
but the virtual machine semantics do not magically vanish.

>>[fancy automatic volatility detection] requires knowledge of the
>>machine internals ....

>Most compilers know nothing of a machine's internals.

And this is considered a virtue.  I say not.

>... Which physical memory locations are going to be volatile may not
>be known when the program is written,

Were that the case, not even the programmer would know where to insert
`volatile' declarations.

>and certainly not when the compiler is written.

Quite probably not.  Hence it should be runtime configurable.  (This is
a `quality of implementation' issue, given the existing draft standard.)

>The situation is similar for MSDOS machines. The compiler does not know
>whether a piece of code will be executed with EMS, EEMS, company X's
>I/O board in slot Y, or all of the above. The programmer does.

Then the programmer can select which map file the compiler should see,
so that the compiler can error-check the programmer's declarations, or
in a more ambitions system, correct or create them.

>Don't be a Unix chauvinist.

All I did was to hold up one example of a number of systems that have
managed without `volatile': an existence proof, as it were, that
volatile is *not necessary*.  I can use a similar proof to show that C
is not necessary---e.g., MVS.  Does that make me an IBM chauvinist?
(That I detest MVS is irrelevant.  I also happen to like `volatile'.)
-- 
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