Path: utzoo!mnetor!uunet!husc6!mailrus!umix!umich!mibte!gamma!ulysses!andante!alice!tve
From: tve@alice.UUCP
Newsgroups: comp.arch
Subject: Re: SPARC and multiprocessing
Message-ID: <7847@alice.UUCP>
Date: 4 May 88 23:24:22 GMT
References: <1671@alliant.Alliant.COM> <1988May2.095624.306@mntgfx.mentor.com>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 21
Keywords: virtually-indexed/physically-tagged caches

As far as the "new virtually indexed, physically tagged write-through
cache" in the Apollo goes, there ain't anything *new*. The name implies
they use the virtual address to address the cache and then compare
the tags to the result of the translation, which will have occured
simultaneously (remember: the TLB is a cache as well and thus has about
the same access time).
Since nothing comes for free (usually), there is a penalty using this
scheme: the cache set size is limited by the number of address bits
available before translation (i.e. the bits which aren't translated).
This usually means the cache set size is limited to the size of a page.
This number is usually around 4Kbytes these days. If you want a larger
cache, you have to make it set associative, which is a pain in discrete
logic (multiplexing etc...).
I think the virtual-index/physical-tag caches will become very attractive
when integrated on a chip, since on a chip, set associative caches are
easier to build and are are anyway (more or less) required for speed.

Thorsten von Eicken
AT&T Bell Laboratories
research!tve
tve@research.att.com