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