Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!ihnp4!illusion!marcus
From: marcus@illusion.UUCP (Marcus Hall)
Newsgroups: comp.lang.c
Subject: Re: volatile, noalias and optimization
Message-ID: <176@illusion.UUCP>
Date: 30 Apr 88 00:02:47 GMT
References: <20345@pyramid.pyramid.com> <132@atpal.UUCP> <3637@haddock.ISC.COM> <135@atpal.UUCP>
Reply-To: marcus@illusion.UUCP (Marcus Hall)
Organization: Magic Numbers Software, Bloomingdale, IL
Lines: 57

In article <135@atpal.UUCP> tneff@atpal.UUCP (Tom Neff) writes:
>In article <3637@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) asks:
>>In article <132@atpal.UUCP> uunet!pwcmrd!skipnyc!atpal!tneff (Tom Neff) writes:
>>>This is a wonderful feature ... but shouldn't we use
>>>        #pragma volatile(var1, var2, var3)
>>>instead of imposing a new keyword on the language grammar?
>>
>>Unless you expand on this a bit, it's not as powerful.  I've actually used the
>>declaration "char volatile * volatile p;" (a volatile pointer to volatile
>>memory) -- would your proposal handle this?
>
>You're right, Karl, the #pragma approach wouldn't work for nested volatile
>references like your example, and I can't think of a graceful way to extend
>my proposal to deal with it either.

Well, actually I would think that this could be expressed thusly:

char *p;
#pragma volatile(p, *p)

The problem with this whole approach, however, is that #pragma is explicitly
left undefined in ANSI-C.  Any compiler implementer is free to do whatever
he/she feels like for #pragma.  ANSI-C merely defines #pragma to be a standard
escape to non-standard directives.  Thus, one compiler may implement this in
the method mentioned above, but another may implement it as:

#pragma vol p; *p;

or any number of different ways.  Usage of #pragma is by definition
non-portable.  It is just there for an escape for local additions that may
be important enough to add despite the non-portableness.  A concept of
volatility is important enough (in my opinion, and in quite a few others)
that a standard, portable way of specifying this is desirable.

Most programs can just ignore volatile and everything will work just fine.
Older compilers can just ignore the keyword and assume everything is
volatile just like current compilers.  Smarter compilers can take advantage
of this to avoid re-loading a register with a variable that was already there,
avoid doing extra writes to memory, etc.

Noalias does enable many optimizations, but while most variables are normally
not volatile, most variables ARE noalias.  Variables that should be declared
volatile are easy to identify; globals that are actually memory mapped i/o
registers, variables that are accessed by signal catchers or interrupt
routines, etc.  Maybe it would make more sense to define a keyword "aliased"
which would be tagged onto variables that actually ARE referenced by
multiple means and let the compiler treat variables as noalias unless it
has its address taken or it is declared "aliased".  Of course, globals
would need to be declared "aliased" if its address were taken *anywhere*.

Anyhow, it seems that noalias should be implemented by some compiler somewhere
through a technique similar to what you have proposed before it gets worked
into the standard.  If it really works and there aren't subtle disasters that
arise from its implementation, THEN incorporate it into ANSI-C-rev2.

Marcus Hall
..!{ihnp4,mcdchg}!illusion!marcus