Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Translating 64-bit addresses
Message-ID: <46133@mips.mips.COM>
Date: 23 Feb 91 21:03:25 GMT
References: <6590@hplabsz.HP.COM>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 48

In article <6590@hplabsz.HP.COM> connors@hplabs.hp.com (Tim Connors) writes:
>Now that we've entered the brave new world of 64 bit (flat) address spaces,
>is it time to revive the old flame wars on address translation mechanisms?
...
>I can think of alot more questions, but I'll leave it there except to ask
>if anyone from MIPS can tell us how you intend to do address translation on
>the R4000?

The general approach (which is about all I can talk about right now)
is essentially identical to the R3000's, although low-level details
differ:
	1) Generate an adddress.
	2) Send it to the TLB
	3) If it matches, translation is done.  Do protection checks
	as needed.
	4) If no match, stuff the offending address and/or appropriate portions
	thereof into coprocessor-0 registers, and invoke a special
	fast-trap kernel routine to refill the TLB.  Different environments
	use different refill routines, depending on their preference
	for PTE layouts and organization.

At this level of discourse, the main difference is the ability for each entry to
map from 4KB -> 16MB.  Obviously, it is trivial to use the big entries
for things like frame buffers, but (in my opinion) it will be useful
to end up with OSs that can use larger pages when they need to.  This is already
an issue with DBMS and scientific vector code, where it is quite possible
to overpower any reasonable-to-build TLB if it maps only 4K or 8KB pages,
regardless of whether it uses hardware or software refill.
(True regardless of 32 or >32-bit addressing).  There are various
ways of coding refill routines that provide mixed-page sizes;
I did one as an example while back that looked like it cost just
a few more cycles, so I believe that it is practical.

Note: I occasionally see marketing-stuff that claims that hardware
refill is much better than software refill. I might believe this
if somebody showed numbers, also....

BTW: back to the oppurtunity cost of 64-bit integers.  I went back
to the plot, and measured the datapath itself a little more carefully,
as my earlier figures included datapath + associated control.

Now, it looks like the die cost of 64-bit integers is more like
4-5%, not 7%.
-- 
-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, 930 E. Arques, Sunnyvale, CA 94086


Brought to you by Super Global Mega Corp .com