Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.lang.c
Subject: Re: volatile: is NOT a frill, is increasingly necessary
Message-ID: <1989@winchester.mips.COM>
Date: 6 Apr 88 05:10:11 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <1878@rtech.UUCP> <1988Mar29.162711.12610@utzoo.uucp> <1988Mar30.110820.23882@light.uucp> <1975@winchester.mips.COM> <4268@ihlpf.ATT.COM>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 40
Keywords: optimizing compilers

In article <4268@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>In article <1975@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes:
>>	a) Our compiler team put in volatile, and until
>>	b) We got volatile to act completely right. [nontrivial]

>In other words, you implemented 'volatile' to conform with the final
>definition in the ANSI standard??  What powers of prediction you have!!  :-)
>What are you going to do if volatile doesn't act quite the way you defined
>it when your compiler team put in volatile??

Change it, of course.  However:
1) During standards efforts, if you're either involved with the efforts,
	or talk to people who are, it's not that hard to get a sense of:
	a) A feature is pretty well-understood, at least in intent,
	and you think that the syntax is going to be left alone, even if
	the descriptive material gets tuned.
	b) A feature is close, but there may well still be some tweaking.
	c) A proposed feature is causing outright battles.

2) In late 1985, it was pretty clear that volatile seemed in category a),
or at worst, b), but certainly not c).  It did not take precognitive
abilities to be able to take a chance on implementing it.

3) The difficulties in getting it right were not in understanding what
it meant, or worrying about how it was supposed to act, they were in
implementing a well-understood intent inside an aggressive optimization
system in a sensible way, when this is a mechanism not otherwise included,
and when meeting volatile's intent required inhibiting more optimizations
than obvious on first glance.
There is of course a very simple way to do it if necessary:  if anything
says volatile, treat the entire C module as though all variables are
volatile other than automatics. This would meet the letter of the spec.
Actually, we also have a -volatile option that says "keep the optimization,
but assume nonlocals are all volatile".  This is very convenient when
first importing some code.  Then you go thru and put in volatile declarations,
and delete the -volatile option.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086