Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!hpda!hpsmtc1!hpisod2!hpihoah!ross
From: ross@hpihoah.HP.COM (Ross LaFetra)
Newsgroups: comp.arch
Subject: Re: Phys vs Virtual Addr Caches
Message-ID: <4420001@hpihoah.HP.COM>
Date: Tue, 28-Jul-87 12:03:48 EDT
Article-I.D.: hpihoah.4420001
Posted: Tue Jul 28 12:03:48 1987
Date-Received: Sat, 1-Aug-87 15:01:31 EDT
References: <3904@spool.WISC.EDU>
Organization: Hewlett Packard, Cupertino
Lines: 55

By the time I read this, many people have responded on a great many different
machines.  Most of the problems/solutions I'll discuss here have been seen
in pieces elsewhere.  But I'll discribe them as they pertain to one machine,
the Hewlett-Packard Precision Archicture, of which the HP9000/Series 840 is
an example (that is out there today):

First of all, for further reading, there is a great deal of information on
the hardware, software, architecture, and operating system (UNIX System V
compatable) in the Hewlett-Packard Journal over the last two to three years.

The HP9000/840 (I'll just call it the 840 from now on) has what is known as
virtual/physical caches (split I and D).  What this means is that the
cache is indexed virtually, but checked (by means on tags) physically.  This
has the advantage of using the cache and TLB (virtual to physical translation
cache) in parallel, which was the purpose of the original basenote.  It also
has the advantage of keeping the cache tag small, because of the limited
physical address space (32 bits on HPPA- HP Precision Architecture), rather
than the large virtual address space (48 bits on the 840, up to 64 bits on
HPPA).

The problem on consistency with shared memory isn't much of a problem.  Since
the machine supports a large number of spaces (32 bit segments of virtual
memory), you can assign each piece of shared memory its own virtual space.
There are 65536 spaces on the 840, so you are not likely to run out soon.
Thus, you can avoid the need to assign a two virtual addresses to the same
physical address.  This is prohibited on HPPA machine (by software convention).

Multi-processor cache consistency (not implemented on the 840 since it is a
uniprocessor) is not a problem either.  Each processor can brodcast the
virtual address as well as the physical address when accessing memory.  In
reality, it is even simpler:  only the cache index needs to be broadcast.

IO presents a bit of a problem, but it is solved from the software side.
Since the OS knows what the IO is going to do, the OS manages the cache
for the IO system.  There are a couple of opcodes that do this.

HPPA solves alot of the problems associated with purging the cache and TLB
on process switches by use of its large address space.  Each process is
assigned its own space(s), and no purgess of either the cache or TLB are
needed on process switches.  Only when spaces are removed is this action
needed.  This allows the 840 to use very large caches (128kb) and large
TLBs (4k entries).  Thus no time is wasted invalidating and reloading
the cache or TLB on process switches (invalidation is typically fast in
other machines I believe, but the reloading happens by missing the cache
and TLB.  Please note that physical caches don't need to do this).

Each process can use its own virtual address zero, because it is really
a virtual offset of zero, where the virtual address is a space and an offset
(each up to 32 bits, for a max of 64 bits in HPPA).

I hope this clarifies some of the issues.  I tried to gather them in one place.
I'm a little weak on the OS side of things, as I'm just a cache designer.

Ross La Fetra
hpda!ross