Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ukma!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: The world is not ready for 'volatile'
Keywords: volatile optimization
Message-ID: <275@twwells.uucp>
Date: 24 Dec 88 21:34:16 GMT
References: <141@bms-at.UUCP>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 75
Summary:
Expires:
Sender:
Followup-To:
Distribution:

In article <141@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes:
: 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"?

While many compilers suck wind, many others are very good.  Also,
remember that some optimizations are easier than others.  The
examples you gave were failures in the peephole optimizer; most such
do their thing by handling special cases. What you found were special
cases not handled by particular peephole optimizers.  Tightening up
the peephole optimizer, past a certain point, is a waste of time: all
additional optimizations will be marginal.

If I had my 'druthers, I'd rather take advantage of volatile instead
of trying to tighten up a peephole optimizer. Why?  Because the
absence of volatile permits me to make wholesale optimizations.  In
other words, if I assume that all variables are implicitly volatile,
I must not assume that the variable retains its values between
accesses; nor may I assume that a write to a variable which can be
determined to be unnecessary (for the algorithm) can be deleted. This
means that all memory references implied by the code must remain
there; this prohibits some of the most effective optimizations from
being done.

Another advantage of this kind of optimization is that it is machine
independent. Many optimizers have two parts, one for machine
independent optimizations and one for machine dependent optimizations.
Compilers that have such often can have the code generators changed,
resulting in a compiler that generates code for a different machine.
Optimizations done that are machine independent will then apply to
all versions of the compiler, not just one.

: 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.

Not true. Consider that a static variable might be accessed from a
function called by a signal handler. In other words, in

	static int Var;

	int
	foo()
	{
		++Var;
	}

Since foo() can be called from a signal handler in another translation
unit, Var is also "volatile".

: In my programs, this is precisely the data requiring the "volatile" keyword!
: (And device drivers would make all magic addresses "extern".)

But you're ignoring an important point: volatile does not only apply
to variables, it also applies to, e.g., things pointed to.  If I were
writing a device driver to handle several devices, I might well
declare a structure containing volatile elements and pass the address
of the structure to some control routine. Or a pointer might well
point to a variable which is changed in a signal handler.

Because of this, any pointed to variable, absent the possibility of
using the volatile keyword, must be considered volatile.

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

On what evidence do you base that?

---
Bill
{uunet|novavax}!proxftl!twwells!bill