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.