rogerh@arizona.UUCP (Roger Hayes) (09/29/84)
(In reference to Guy Harris' contention that a C compiler can't prohibit you
from taking the address of a variable declared "private")
A C compiler most certainly can! Try taking the address of a register
variable.
I like the idea of class private -- it does add to the set of possible
optimizations. Is there a cleaner way to do it? I suppose that the
compiler could collect information about aliasing, but that isn't in
general computable.
Why, oh why, don't C compilers optimize? I am tired of hacking source
in order to get the code I know I want -- the technology certainly
exists to let the compiler do most of that work for me. An example
is using a pointer variable instead of array indexing in a 'for' loop --
for maximum efficiency, I have to write:
{ struct foo *foop = fooarr;
for (i=0, i < FOOMAX; i++)
dostuff(*(foop++));
}
instead of what I mean:
for (i=0; i < FOOMAX; i++)
dostuff(fooarr[i]);
On another issue, I like the recent sugggestion that, in macro expansion,
the formals should have a special status. The formals should be string-
expanded (ie, whether inside quotes or not); other macros should not.
Roger Hayes
University of Arizona, Dept of Computer Science
rogerh@Arizona.CSNET
rogerh@arizona.UUCP
guy@rlgvax.UUCP (Guy Harris) (09/30/84)
> (In reference to Guy Harris' contention that a C compiler can't prohibit you > from taking the address of a variable declared "private") > > A C compiler most certainly can! Try taking the address of a register > variable. What I should have said was that the compiler can't prevent you from stuffing some address that points to that variable into a pointer; the the person I was replying to was saying that "private" wouldn't work in C because the declaring something as "private" doesn't 100% guarantee that nothing can ever point to it. That is true, but not particularly relevant; optimization could reveal bugs (or even cover them up!) by referencing a copy of a variable which changed out from under the copy, but that's not the fault of the optimizer. > Why, oh why, don't C compilers optimize? I am tired of hacking source > in order to get the code I know I want -- the technology certainly > exists to let the compiler do most of that work for me. An example > is using a pointer variable instead of array indexing in a 'for' loop -- > for maximum efficiency, I have to write: > { struct foo *foop = fooarr; > for (i=0, i < FOOMAX; i++) > dostuff(*(foop++)); > } > instead of what I mean: > for (i=0; i < FOOMAX; i++) > dostuff(fooarr[i]); Amen! There do exist optimizing C compilers, but unfortunately PCC, upon which most UNIX C compilers seem to be based, isn't one of them. (I first saw the particular strength reduction you mention in, of all places, the DEC PDP-11 threaded code FORTRAN compiler; it showed up because somebody had written a threaded code to pseudo-C decompiler and ran it on "adventure", and it produced that sort of *p++ code.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy