Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.arch Subject: Re: The & (address) operator and register allocation Message-ID: <584@auspex.UUCP> Date: 5 Dec 88 19:55:44 GMT References: <1224@cps3xx.UUCP> <1988Dec3.221843.28966@utzoo.uucp> <1586@nmtsun.nmt.edu> Reply-To: guy@auspex.UUCP (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 43 >> The original Berkeley RISC design had registers with addresses, carefully >> set up in such a way that you could pass pointers to them around freely. >> The idea was to maximize the ability to put local variables into registers. >> I don't know of anybody commercial who's copied this idea. > >Umm, Henry, doesn't a PDP-10 count? Seemed kinda like a commercial >system to me.... The registers certainly seemed addressable (hey, >you can even point the PC at them and execute code out of them). Well, Henry said "carefully set up in such a way that you could pass pointers to them around freely". Unfortunately, I don't know that the PDP-10 counts here. Consider: foo() { register int x; ... bar(&x); ... } bar(ip) int *ip; { register ac2, ac3, ..., acN; ... } I don't think a naive implementation of this would work. If "x" were in AC2 (or whatever general register 2 was called - it's been a while since I've been anywhere near a PDP-10 or successor), "foo" would, in a naive implementation, pass a pointer containing the bit pattern for "2" to "bar". Unfortunately, when this pointer is dereferenced by "bar", it will still refer to AC2; if "bar" uses AC2 for a variable of its own, this pointer will refer to *that* variable. (An example of a different implementation: if this PDP-10 C compiler used callee-save, you could imagine a compiler generating code to pass the address of the place where AC2 was saved, rather than passing the address of AC2 itself.)