Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site pyramid.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!pyramid!csg
From: csg@pyramid.UUCP (Carl S. Gutekunst)
Newsgroups: net.arch
Subject: Re: Re: Cache Revisited
Message-ID: <15@pyramid.UUCP>
Date: Fri, 6-Sep-85 00:00:17 EDT
Article-I.D.: pyramid.15
Posted: Fri Sep  6 00:00:17 1985
Date-Received: Sat, 7-Sep-85 06:46:42 EDT
References: <170@mips.UUCP> <455@mtxinu.UUCP>
Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst)
Distribution: net
Organization: Pyramid Technology, Mt. View, CA
Lines: 24

>>Consider the ultimate
>>case: a smart compiler and a machine with many registers, such that
>>most code sequences fetch a variable just once, so that most data references
>>are cache misses.  Passing arguments in registers also drives the hit
>>rate down.
>
>With this ultimate machine/compiler combination it seems intuitively
>that a data cache would then be a *bad* idea, since having a cache
>can't be faster than an uncached memory reference (for what would
>be a miss) and is often slower.  We can then use the real estate saved
>for even more registers!

In fact, a data cache greatly improves throughput on real large-register-set
machines, like the Pyramid. Many operations in program development (e.g.
compiling) require repetitive searching/sorting on moderately large arrays;
the data cache can help out here a lot. It also helps when you have to save
all those registers during a context switch. 

What we really need is a machine with 64K 32-bit registers. :-{)
-- 
      -m-------   Carl S. Gutekunst, Software R&D, Pyramid Technology
    ---mmm-----   P.O. Box 7295, Mountain View, CA 94039   415/965-7200
  -----mmmmm---   UUCP: {allegra,decwrl,nsc,shasta,sun,topaz!pyrnj}!pyramid!csg
-------mmmmmmm-   ARPA: pyramid!csg@sri-unix.ARPA