The world is not ready for 'volatile'

[Stuart Gathman]

With all this talk about 'volatile' being necessary for good optimization,
I wonder why compilers don't do the optimizations already available without
it?  Examples,

	mov.l	d5,d0
	mov.l	d0,d4			; typical "optimized" code !
	mov.l	&0,d0

	or

	mov.w	&1234,d0
	ext.l	d0
	sub.l	d2,d0			; "optimized" code . . .
	mov.w	d0,&5678

	or (for Intel fans)

	register char far *p;
	...
	p->a = 1;
	p->b = 2;

	becomes (on MSC & Turbo C)

	les	bx,[bp-4]
	mov	byte ptr es:[bx],1
	les	bx,[bp-4]		; "optimized" code !
	mov	byte ptr es:[bx+1],2

I could go on and on.  I have used Aztec, Turbo, MS, Motorola,
GCC (better than most), Convergent Technologies (the worst), 
and many other compilers.

When compilers don't take advantage of existing optimizations,
what's the big deal about "volatile"?

Furthermore, all "auto" and "register" variables are subject
to the same optimizations as (absence of) "volatile" gives you if their
address is never taken (and "noalias" to boot).  If you optimize
"static" data as well, only "extern" data gets volatile treatment.  
In my programs, this is precisely the data requiring the "volatile" keyword!
(And device drivers would make all magic addresses "extern".)

If compilers would simply use the optimization opportunities already
available, the improvement with "volatile" would be marginal.

P.S.  don't post counter examples like:

	int a,b, *p = &a;
	p[1] = 2;

      this is not portable 'C' (or even good programming).
-- 
Stuart D. Gathman	<stuart at bms-at.uucp>
			<..!{vrdxhq|daitc}!bms-at!stuart>