Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!apple!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Instruction caches and closures
Message-ID: <39868@mips.mips.COM>
Date: 3 Jul 90 07:30:34 GMT
References: <1694@kunivv1.sci.kun.nl> <YUHARA.90Jul2185235@minako.stars.flab.fujitsu.co.jp> <24891@bellcore.bellcore.com> <1756@charon.cwi.nl>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 22

In article <1756@charon.cwi.nl> jack@cwi.nl (Jack Jansen) writes:
>This I/D cache discussion sparked a thought: I get the impression that
>separate I/D caches are used mainly to get the benefit of two-way
>set associative caches without the cost involved. If there aren't any
>other added advantages,...

No, the main reason is to double the peak bandwidth from cache -> CPU
with the same speed SRAMs.  The more usual effect is that a RISC CPU
can fetch an instruction every cycle, and could still do a load or store
every cycle without penalty.  Of course, realistically, since the usual
rule of thumb is 20% loads, 10% stores, using a joint cache would
give you a 30% cycle count increase, assuming a 1-cycle hit per load/store.
Straighforward writeback caches may add more, double-width I-fetches
may reduce the penalty, etc, etc.  In general, the decision to use
split caches comes from the wish to avoid this overhead.
The effect that partially simulated 2-way set-associativy is OK, also.
pp. 423-425 of H&P, also section 6.4.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086