Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!magic!stewart
From: stewart@magic.UUCP
Newsgroups: net.arch
Subject: Re: How Many Virtual Spaces (minor
Message-ID: <430@magic.DEC.COM>
Date: Wed, 23-Apr-86 03:08:54 EST
Article-I.D.: magic.430
Posted: Wed Apr 23 03:08:54 1986
Date-Received: Thu, 24-Apr-86 06:39:31 EST
References: <2089@peora.UUCP> <5100065@ccvaxa>
Reply-To: stewart@magic.UUCP (Larry Stewart)
Organization: DEC Systems Research Center, Palo Alto
Lines: 24

A physical address cache need not suffer in performance because one must
somehow do the virtual to physical translation "first."  The early
Stanford Sun boards, for example, applied the high order bits of the
virtual address to the TLB and the low order bits to the cache tag 
memory and the physical page number came out of the TLB just in time
to be compared with the cache tag, giving a hit or miss indication.

The particular implementation had some oddities like the page size
equalling the cache size, but having them be different doesn't hurt
too much.

For example, if the page size is smaller than the cache size (likely,
these days) then it might appear that you need some bits of the
physical page number to address the cache tag memory, but that can be
solved by requiring that a few low order bits of the physical page number
match the low order bits of the virtual page number.   Any real
memory allocator worth its salt should be able to deal with that
kind of restriction.

If the page number and cache size overlap by, say, two bits, then one
could also look up the four possible tags and then select, based on
the TLB output.  Kind of a set associative trick....

Let your imagination roam.  -Larry