Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!eric
From: eric@pyrps5 (Eric Bergan)
Newsgroups: comp.lang.c
Subject: Re: volatile
Message-ID: <20345@pyramid.pyramid.com>
Date: 21 Apr 88 16:49:53 GMT
Sender: daemon@pyramid.pyramid.com
Lines: 38

In article <488@wsccs.UUCP>, terry@wsccs.UUCP (Every system needs one) writes:
> 
> Machine dependancy is the responsibility of the compiler writer. 
> Optimization is the responsibility of the compiler writer.
> If architectural differences prevent effective use of the compiler, this is
> the responsibility of the compiler writer.

	I agree with these, but does this imply:

If language deficiencies prevent effective optimization, scrap the 
optimizations?

	The key question seems to be, "Is C (particularly K&R) perfect?".
Are we willing to add constructs to the language that both better document
what is going on and provide the ability to do better optimization (and hence
get better performance)? "volatile" not only helps the optimizer, I would
suggest it also helps document what is going on.

	The flip side of the argument is "How far should we bend C for
optimization purposes?" It would be great from an optimizer's viewpoint
to be able to definitively know if a variable has no aliases. I suspect
that this is too traumatic a change for the language, however, so
we will have to rely on doing less optimization then might be available.
(Have there been any studies of just how much performance improvements
might be possible if an optimizer definitively knew what was and was
not aliased?) Notice that noalias also does not really better document
the program - although an "aliased" keyword might. But even then, there
is simply too much pointer use going on to expect the average software
house to rewrite all their code using either an "alias" or a
"noalias". (Note that the use of "volatile" is much less frequent, so
the pain of converting to that is much less. Also, aggresive optimizers
are already causing developers using volatile variables problems.)

	One other side point. There have been a few suggestions that
why worry about the optimizers, let's just keep building faster
hardware.  I'd like to point out that as the hardware continues to get
faster (and rely more heavily on register access, or keeping pipelines
running), the optimizer must get more sophisticated to take advantage
of that hardware, otherwise no performance improvement will be seen.