Path: utzoo!mnetor!uunet!husc6!hao!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: noalias (Hey buddy, pick on a keyword your own size!)
Message-ID: <9935@mimsy.UUCP>
Date: 23 Dec 87 10:15:40 GMT
References: <10972@brl-adm.ARPA>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 104

[Key point: programmers cannot ignore noalias]

In article <10972@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
>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).

Not all!  Register variables are not aliased; variables whose
address is never taken are not aliased (the latter includes the
former, by definition).  The problem occurs only with variables
whose address *is* taken.  Of course, this includes all the things
to which pointers point.

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

Perhaps there should.  Given that there are no existing implementations
that use `noalias' to do this (MicroSoft C uses a different format,
as several people have mentioned), the perennial `lack of prior
art' alone should keep this from being included in the draft
standard.

>If you don't understand the purpose of noalias then ignore it.
>It won't effect you.  If you do understand it, use it.

[I should say not!  However, it will *affect* others.  But pardon
the spelling gripe.]

This argument sounds familiar.  Wait ... let me think ... ah!
PL/I.  `Sure we can put all this stuff in the language.  Programmers
can pick a subset they like and stick with that.  The stuff they
don't like, they can ignore.'  I dare say it did not work.

>Someone asked, "Why not use violate?"

[This brings some most unusual images to mind!  `What seems to
be the trouble here?'  `He ... he *violated* that variable!'
`Ugh!  What are you, some kind of sicko?'  But again I digress....]

>Good question.  Violate implies that it is a IO location (i.e.
>memory mapped).

No, `volatile' implies that the variable may change `behind the
compiler's back', so to speak, and that stores to it must be done
exactly as written as they may have some external effect.  Shared
memory, for instance, might be `volatile'.

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

Compilers are free to ignore `noalias'.  Programmers are not.  Here
is why:

	f() {
		noalias int a;
		...
		a = e;	/* e is any expression that evaluates to >=38 */
		g(&a);
		a *= 2;	/* the compiler might use e + e */
		...
	}

	g(int *p) {
		if (*p < 38) *p += 4;
	}

If you do not understand `noalias', and change the code in `g'
or the value of `e', you may change a correct program (in which,
after `a = e' in f(), a >= 38) to an incorrect one (in which,
after `a = e' in f(), a < 38, or g() alters *p even when *p >= 38.)

The definition of `noalias' may be such that the program fragment
above is already invalid.  In that case I could devise an even more
convoluted example which could have the same effect.  The point is
this:

* Whatever `noalias' means[1], it has semantics that may be visible
* to the program[2], and hence must be visible to the programmer.

Unlike `register', if you ignore those semantics, you may get a
program that quietly fails.  Ignoring the semantics of `register'
produces only a compile-time error.

-----
[1] It is probably either `I will create no aliases' or `those
aliases I create never alter the value of a variable'.  Both are
impossible for compilers to verify (at compile time).
[2] If the programmer lies, the program is incorrect, but the
compiler cannot detect all possible lies, so the programmer must.
-----

I would like to see the proposed definition of `noalias', as it
may prove that many regular variables (those that are neither
noalias nor volatile) have the same semantics as volatile as far
as read access goes, the only difference being that writes can be
deferred or eliminated.  (It depends on the semantics allowed for
asynchronously invoked code (signal handlers).)  They may even have
the same write semantics.  Or, again depending upon each definition
and all their interactions, they may not have similar semantics at
all.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris