From: mash@mips.com (John Mashey)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 7 Apr 1992 01:36:17 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <MEISSNER.92Apr6102821@tiktok.osf.org> meissner@osf.org (Michael Meissner) writes:
...
>Finally, with regard to global addresses, I notice that botht he R4000
>and Alpha do not deal at all well with global/static variable
>addresses being more than 32-bits.  I think that there is an implicit
>assumption that linkers won't put things above the 4G limit.

I don't think this is necesarily the case.  I don't know what the Alpha
software actually does, but MIPS software (right now):

1) Gives you 64KB of directly-addressed variable relative to the
"gp" (global pointer register).  It turns out that this captures most
"small" variables in most programs (that I've looked at in UNIX-land,
anyway).
	LW	Y,offset(gp)

2) For other directly-address variables, you must do:
	LUI	X,upper-16bits
	LW	Y,lower-16bits(X)
[With note of Michael's about sign-extension issues]

3) For MIPS  for "big" addresses, you can do something like:
	LD	X,zzz(gp)	[i.e., get the literal address from the
	LW	Y,0(X)		gp area)
or
	LUI	Z,upper
	LD	X,lower(Z)	[get the 64-bit address from anywhere in
				lower 32-bits].
	LW	Y,0(X)
Of course, some of these incur extra stalls if the load delays cannot be
scheduled away.
*These are MIPS examples, but are fairly typical of what many RISCs do.**

3) Sometime, a long time ago, we discussed the idea of putting something
in to generate a 64-bit constant easier ... but came to the conclusion
that the frequency of needing this particular one were so low that we need
do nothing special.  [And the Alpha folks must have reached the same
conclusion, even starting with a 64-bit archiecture from the beginning.]
No RISCers appear interested in adding instruction formats [especially
non-32-bits ones:-] to deal with this more efficiently.

4) As to the programming model considerations that induce us to believe
this is OK:
	Programs that use large amounts of data do so, because:
		1) they have big arrays
		2) they have big dynamically-allocated areas
	Put another way, people just don't use that many small
	variables for this to be an issue.  For FORTRAN common blocks
	that contain numerous small varialbes, you can create the
	address of the beginning of the COMMON, and leave it in a register
	if that makes sense.  Current compiler technology handles this
	fine....
5) Certainly any reasonable software system will do its best to keep
frequently-used small scalars "near" a gp, or at least in the first
4GB of address space.  Consider this:  suppose you allow 16 bytes
for "small" data items (variables, small structures & small arrays),
and you sort things so the smaller ones stay below 4GB.
Sppose your memory map would allow 2GB for such use.  That gives you:
2**(31-4) = 2**27 = 512 Million such data items...
	Somehow, I do *not* expect, *ever* to see a human-generated
	piece of code with 512M data items that each have their own names...
	(machine-generated: maybe, but not humans)
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Xref: sparky comp.arch:4964 comp.ai:1975