Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site celerity.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!celerity!boston
From: boston@celerity.UUCP (Boston Office)
Newsgroups: net.arch
Subject: Re: Re: Cache Revisited
Message-ID: <347@celerity.UUCP>
Date: Wed, 18-Sep-85 14:36:52 EDT
Article-I.D.: celerity.347
Posted: Wed Sep 18 14:36:52 1985
Date-Received: Mon, 23-Sep-85 00:34:37 EDT
References: <170@mips.UUCP> <455@mtxinu.UUCP> <645@mmintl.UUCP>
Reply-To: boston@celerity.UUCP (Boston Office)
Distribution: net
Organization: Celerity Computing, San Diego, Ca.
Lines: 22

In article <645@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>
>In article <455@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:
>>In article <170@mips.UUCP> mash@mips.UUCP (John Mashey) writes:
>>
>>>                                                 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!
>
>Not necessarily.  When a context switch takes place, you would have to
>save all the registers.  The cache can, at worst (best?) be dumped.

However: if you have enough registers, and manage them in banks,
they only need be saved if you run out of BANKS of registers.