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.


Brought to you by Super Global Mega Corp .com