Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and restraints on optimization
Message-ID: <6264@mimsy.UUCP>
Date: Sun, 12-Apr-87 00:00:14 EST
Article-I.D.: mimsy.6264
Posted: Sun Apr 12 00:00:14 1987
Date-Received: Sun, 12-Apr-87 19:37:30 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <995@wanginst.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 94

In article <995@wanginst.EDU> mckeeman@wanginst.EDU (William McKeeman) writes:
>Conclusion: when making a pitch for a better C definition rule, identify
>which of the problems:
>    unrestricted optimization
>    overflow anomalies
>    roundoff anomalies
>    side effect anomalies
>it is designed to solve.  If you don't intend for your rule to have
>language-wide implications, state the limited area of application.

Here is a question:  Which of those problems are sidestepped by
volatile variables?  I would guess that at least roundoff anomalies,
as demonstrated by the code fragment

	double a, b, n, d;

	a = n / d;
	func();		/* clobber fp accumulator */
	b = n / d;
	if (a != b)
		printf("eh?\n");

where a 64-bit `a' might be compared with an 80-bit accumulator,
would be avoided if `b' were declared `volatile'.  But there may
be more to this.

Just what does `volatile' *do* in a compiler?  What are the precise
semantics of volatile variables?  If a volatile variable is just
one whose value can never be assumed from context, a compiler could
eliminate `dead' stores, so this definition is clearly wrong:

	volatile v;

	v = 0;
	v = 1;
	/*
	 * Altering this to just `v = 1' makes no assumption about
	 * previous values of v, but is no doubt not what is desired.
	 */

I am not quite comfortable with the definition `a volatile variable
is one which may never be used in any optimisation', but if we take
this as a working definition, what are the semantics of volatile
variables within larger expressions?  Could this be extended somehow
to include a concept of volatile expressions?

Let us use as another example the h-bar expression someone noted
recently:

	answer = value / h_bar / h_bar;

which, since h_bar is small, is not the same as

	h_bar_squared = h_bar * h_bar;
	answer = value / h_bar_squared;		/* division by zero */

If we have

	/*
	 * Using eV-sec is cheating, since we can represent its square
	 * (handy having a physics book lying around at home!).
	 */
	volatile double h_bar = 6.626e-34/(2*PI);/* J-sec */

it is then obvious that the compiler cannot optimise the
expression

	answer = value / h_bar / h_bar;

We will run into trouble, however, if we use

	#define PI	3.1415926535897932384626433832795
	#define h_bar	(6.626e-34 / 2 / PI)
	...
	answer = value / h_bar / h_bar;

since we now have a floating point constant.  (Of course, if the
optimiser is smart *enough*, it will notice that h_bar*h_bar is
zero and not do the `optimisation'

	h_bar_squared = h_bar * h_bar;
	answer = value / h_bar_squared;

but assuming this is also cheating.)  I now run a bit out of my
depth, not having the ANSI draft handy, but propose the definition

	#define	h_bar	((volatile double) (6.626e-34 / 2 / PI))

Since the semantics of a cast are precisely that of assignment to
a variable of the same type as the cast, this would seem to solve
the immediate problem.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu