Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC vs CISC simple load benchmark; amazing ! [Not really]
Message-ID: <39439@mips.mips.COM>
Date: 18 Jun 90 02:48:47 GMT
References: <8019@mirsa.inria.fr> <39319@mips.mips.COM> <675@sibyl.eleceng.ua.OZ> <39397@mips.mips.COM> <61780@lll-winken.LLNL.GOV> <137441@sun.Eng.Sun.COM>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: Your Organization Goes Here
Lines: 37

In article <137441@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
>>| Of course, any given machine can be done in this way.
>>
>>  While I agree with you that one can always come up with cache-busting code,
>>I think that you picked a particularly bad example as I think that the cache
>>design in question is just brain dead.  If you design a direct mapped cache
>>you should have at least two buckets for each cache line.

>Excuse me, but isn't what you are describing a two way set associative cache?

>Furthermore, I believe that John's point was that you can take *any* caching
>scheme and break it.  Suppose that we had a cache like you described.  It
Yes, this was not picking on Sun (all of MIPS' caches are direct-mapped, too,
except the RC6280's second-level cache, although we do tend to use
physical-tagged caches most of the time for other reasons, not relevant
to the single-threaded discussion of arrays & such).

>Finally, you may or may not be correct in your assessment that direct mapped
>caching schemes are "brain dead" but you ought to consider what is involved
>in making a cache N-way set associative.  It takes up a lot of real estate
>and if N is even slightly large, it can add extra gate delays in the
>critical path of looking for a hit (last I looked fan in on AND gates wasn't
>that large, but maybe that's changed).

Yes.  Look at Steve Pryzblksi's thesis and/or the Morgan Kaufmann book;
also, there have been several papers analyzing direct-mapped caches
versus set-associative ones in various design environments, and finind
that they are very competitive in those environments where
set-associative is not already strongly imnplied for other reasons.

Set-associativity is always nice when you can get it, and sometimes
it's the right thing, sometimes not.
-- 
-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