Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: Instruction cache for AMD 29000
Message-ID: <28200060@ccvaxa>
Date: Tue, 27-Oct-87 21:38:00 EST
Article-I.D.: ccvaxa.28200060
Posted: Tue Oct 27 21:38:00 1987
Date-Received: Sat, 31-Oct-87 01:44:52 EST
References: <443@root44.co.uk>
Lines: 25
Nf-ID: #R:root44.co.uk:443:ccvaxa:28200060:000:1237
Nf-From: ccvaxa.UUCP!aglew    Oct 27 20:38:00 1987


..> Caching in physical vs. virtual space.

The basic reason to do caching by virtual address is speed, if your cache
is tightly bound to your system: it means that you can start a cache access
before doing a virtual-to-physical translation.
	Various people have pointed out that if you are lucky, you can
start the cache access with bits of the virtual address that aren't
affected by the translation; and then, of course, there is AMD, whose
"carefully tuned pipeline architecture" eliminates the need to do almost
any work at all :-).

Apart from that a physical cache wins just about hands-down over a virtual
cache: it is easier to keep consistent, easier to share among multiple
processes, and so on.


Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms.arpa

I always felt that disclaimers were silly and affected, but there are people
who let themselves be affected by silly things, so: my opinions are my own,
and not the opinions of my employer, or any other organisation with which I am
affiliated. I indicate my employer only so that other people may account for
any possible bias I may have towards my employer's products or systems.