volatile: a summary

[Chris Torek]

In article <705 at garth.UUCP> smryan at garth.UUCP (Steven Ryan) writes:
>This is getting ridiculous. I propose a formal schism between the AI church
>that believes computers can do anything and a pragmatic church that believes
>computers are stupid.

(Apologies for the harsh tone, but it is obvious that those who are
objecting to my reasoning have not thought about implmentations and
their difficulties.  I thought a bit of chastisement in order. :-) )

I am guessing that this is in response to my suggestion that whenever a
programmer can discover that *(int *)0xf0 is not volatile, but *(int *)
0xff4 is, by reading a manual, a hypothetical perfect compiler can do
the same by reading `(the electronic version of) the manual'.

Those who believe that this implies `computers can do anything' have
not exercised their brain cells about it.  Why must the compiler's
version of the manual be the same as the programmer's, or even be
exclusively in some natural language?  The compiler's electronic
version of the manual might even read

	volatile 0xff0..0xf9f

In this case, even though the word `volatile' appears *somewhere*, it
is nowhere in the C source, and hence the language proper has no
volatile keyword.

For those who will claim that this is mere trickery, again, you have
not thought hard enough about the issue.  Instead of `volatile
0xff0..0xf9f' the manual might instead say `ram 0x0..0xeff; ram
0x4000..0xbfffffff'.  Instead of saying what *is* volatile, this says
what *cannot* *be* volatile.  And if the electronic manual does not
exist, or if my hypothetical perfect compiler does not exist, as it
does not, or even if it *cannot* exist, what then?  Is the volatile
keyword necessary?  No.

Consider the IBM PC.  (This since I was flamed for using Unix compilers
as an example.) In the following (toy) large model program, which
assignments might be (not *are*, just *might* *be*) volatile?

	#define DISPLAY 0xc000000	/* or whatever */

	main()
	{
		int i, *p1, *p2;

		p1 = &i;			/* 1 */
		p2 = (int *)DISPLAY;		/* 2 */
		*p1 = 3;			/* 3 */
		*p2 = 'k';			/* 4 */
		for (; i < 100; i++) {
			if (rand())
				p1 = p2;	/* 5 */
			*p1 = 0;		/* 6 */
		}
		exit(0);
	}

Even without knowing whether 0xc000000 is display RAM, I can accurately
predict that assignments number 1, 2, 3, and 5 are *not* into volatile
memory; only assignments 4 and 6 can possibly write volatile locations.
Whether 4 and 6 actually do write volatile locations (and if I got
the display address right, they do not) is not important: all the
other assignments do not, and may therefore be optimised.

If you claim that this analysis cannot be extended beyond toy programs,
then again you have not used your brain.  It not only *can* *be* done,
it *has* *been* done.  You can buy a C compiler today% that does
cross-module optimisation.  That compiler may not run on an IBM PC.
Well, I never said it would be *easy*.  And that compiler may produce
suboptimal code for assignments that *could* *be* volatile but (as it
happens) are not.  Well, I said that too.

If you believe this argument means I think the volatile keyword is bad,
go back and read <11837 at mimsy.UUCP>.  All I have said is that the
keyword is not necessary, not even for optimisation.

-----
% One such compiler is the one MIPS uses.  I know it does final code
generation at link time.  Whether it tries to do alias detection at
this time I cannot say; but ruling out volatility is a special case
of alias detection (`does this pointer alias an unknown variable').
Given that their compiler has the `volatile' keyword, I imagine it
does not bother.
-- 
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