Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!killer!usl!usl-pc!jpdres10
From: jpdres10@usl-pc.usl.edu (Green Eric Lee)
Newsgroups: comp.lang.c
Subject: Re: Addresses of parameters
Message-ID: <84@usl-pc.usl.edu>
Date: 31 Oct 88 17:12:50 GMT
References: <35620@XAIT.Xerox.COM> <10124@haddock.ima.isc.com> <35664@XAIT.Xerox.COM> <10164@haddock.ima.isc.com>
Reply-To: elg@killer.UUCP (Eric Lee Green)
Organization: Univ. of Southwestern La., Lafayette
Lines: 27

In article <10164@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <35664@XAIT.Xerox.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>>Are you sure, by the way, that such a guarantee is in the major language
>>specifications?  Taking an address is not invariably guaranteed.
>
>Yes, I'm sure.  It's implicit in K&R (which is not, and was not intended to
>be, a precise language specification).  According to the dpANS (the formal
>spec), the only lvalues that cannot be &'d are registers and bitfields.
>(There also exist lvalues that are not modifiable, namely arrays and consts;
>this is an orthogonal concept.)

Note that many machines with large register sets or register windows
machines have optimizing compilers that keep ALL local automatic
simple variables in registers, not only variables declared
specifically as "register". This wrecks havoc with Unix. That's why
the Pyramid 90x has the bogosity of a memory-mapped register window
stack (so that you CAN take the address of a variable and have it mean
something). That won't help the AMD29000 or the SPARC much, though. I
suspect that what will happen then is that when the optimizer is
deciding what register to allocate for what, it'll notice that you're
taking the address of that particular variable -- thus forcing it into
RAM, which is a performance hit if you use that variable often (e.g. a
"char *" auto-incremented in a loop will be 6 times slower in RAM on
the AMD than it would be in a register).

--
Eric Green   {mit-eddie,osu-cis,...}!killer!elg, killer!usl!elg