Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!csn!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!sei!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Translating 64-bit addresses
Message-ID: <12151@pt.cs.cmu.edu>
Date: 28 Feb 91 17:22:12 GMT
References: <6590@hplabsz.HP.COM>
Organization: Carnegie Mellon University, CS/RI
Lines: 29


In article <6590@hplabsz.HP.COM> connors@hplabs.hp.com (Tim Connors) writes:
>For 32 bit addresses, Motorola's MC68851 uses a "two level" translation
>tree involving 4K pages (12 bits) and two 10 bit indices, one index for
>each level.  How could this technique be applied to 64 bit addresses?
>Would more levels be needed?  Should the page size be larger?

The MC68851 actually allows a variable number of levels - the table
search flowchart contains a loop.  You may be thinking of its RISC
descendant, the 88200.

There are lots of ways to skin a cat. You can store a complete flat
table in another virtual space, with pages there only being
instantiated on demand. Trees work, and there have been tree methods
that stored "likely" information (eg the descriptor of the first page
of a segment) high up in the tree.  You can punt it all to software,
if the TLB is big enough, or has big or variable page sizes.

Variable page size can be done in software. (Mach's boot can select a
software page size - of course, it has to be a multiple of the
hardware size.) The CDC Star-100 allowed multiple hardware page
sizes, simultaneously, as part of their plans for memory mapped I/O.
The 88200's BATC is a 10 entry TLB, each entry mapping an aligned 512
KB region. (This, like the new MIPS stuff, is aimed at big address
spaces, not big I/O.)


-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon Robotics