TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU (12/23/87)
I can't believe what I am reading.
First of all, mmdengl@cuuxb.ATT.COM on 22-Dec-87 did the best job
so far de-confusing the whole noalias situation.
Let me try to state more clearly what I said before.
Currently, K&R (and every compiler you've used so far) has been
forced to assume (for safety) that your variables are NOT NOALIAS
(i.e. they ARE assumed ALIASED).
All ANSI is saying is that there should be a way for a programmer
to point out to the compiler that, "Hey, this is a safe variable...
let your optimizer have a field day."
(for this next paragraph, flame directly to me TLIMONCE@DREW.bitnet):
(It's a bit blunt... or should I say "rude"?):
If you don't understand the purpose of noalias then ignore it.
It won't effect you. If you do understand it, use it.
Someone asked, "Why not use violate?" Good question. Violate implies
that it is a IO location (i.e. memory mapped). If you have a pointer
to a violate int, that may be pointed to a constant memory location who's
value is (ummm... think of a good example... ummm) the status of a serial
port. noalias implies that the location will change due to pointers.
Arrrgh! We're wasting all this time talking about something that doesn't
affect you unless you are a compiler writer! Programmers should say,
"noalias? Nice little keyword, maybe I'll use it if I need to
someday." Compiler writers should be saying, "noalias? Doesn't bother
me!" or "Good, now I can do a new-and-funky optimizer."
Not only can the programmer just plain ignore it if s/he doesn't want to
use it, a compiler writer can "ignore" it and generate code as usual.
Just like "register", many don't use it and many compilers ignore it.
(Ummm, ignore it for different reasons that noalias though).
As far as a new method for pragmas, someone suggested allowing:
int (pragma-this, pragma-that) *i;
That's interesting, but talk about "extreme modifications to C". Let's
not make C another pascal or fortran. This is something that a compiler
writer may want to add so that Standard II will include it as prior art.
I would group all those (violate, register, const, noalias, etc) into
allowing this as well as making it a standard platform for other ideas.
Maybe a clause that allows the compiler to just warn about unrecognized
options in this situation like a pragma. But let's leave this for the
next standard.
Tom Limoncelli
tlimonce@drew.BITNET
Disclaimer: If you believe a word I say it's a miracle. ASCII subliminal
messages haven't been invented yet.
--------------------------------------------------------------------------ok@quintus.UUCP (Richard A. O'Keefe) (12/24/87)
In article <10972@brl-adm.ARPA>, TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: > Someone asked, "Why not use violate?" Good question. Violate implies > that it is a IO location (i.e. memory mapped). If you have a pointer > to a violate int, that may be pointed to a constant memory location who's > value is (ummm... think of a good example... ummm) the status of a serial > port. noalias implies that the location will change due to pointers. Presumably he means 'volatile'. 'volatile' does NOT mean "IO location". It means "hey Mr compiler, this may change when you're not expecting it, so each reference had better use the original rather than a copy". One reason for wanting it in all C compilers, not just ones on micros, is that a volatile location may be changed by a signal handler. E.g. volatile int ticks; int ordinary; my_alarm_handler() { ticks++; CHECK( alarm(1) ); } main() { int i; ticks = 0; CHECK( signal(SIGALRM, my_alarm_handler) ); CHECK( alarm(1) ); i = ticks; ordinary = 1; printf("ticks = %d, ordinary = %d\n", ticks, ordinary); } The point is that a C compiler *may* treat the printf() call as printf(..., ticks, 1); mut *may not* treat the printf() call as printf(..., i, ordinary); nor as printf(..., 0, ordinary); even though i hasn't changed, so is still "obviously" equal to ticks. This is clearly the right way around: most variables aren't going to change unexpectedly, and it is the abnormal ones which are flagged. It is fairly easy to determine the set of variables which need to be declared volatile: every variable changed by a signal handler and every variable visible to another process (whether mapped I/O, mapped virtual memory, or whatever).