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