Self-modifying code

[John Mashey]

In article <1087 at ficc.UUCP> peter at ficc.UUCP (Peter da Silva) writes:

>	Why are an Icache plus a Dcache better than just
>	a big shared cache as big as both?

1) (Major) with split caches, you can access a word of instruction and
a word of data in the same cycle.  With a joint cache, you get one or
the other.  As a truly gross estimate, expect to lose 10-40% of your
performance, given conflicts between I-refs and loads/stores.

2) Less important, but still useful.  As you make a direct-mapped cache
bigger, each successive 2X improves the hit-rate, but it improves it less than
the last 2X.  At some point, it is hard to make it bigger and keep the same
speed SRAMs, and then the only way (keeping the same organization) to make
the hit rate faster is to make it set-associative.  Given the same total
cache size, hit rates for many programs (not all, there are exceptions):
	joint, direct-mapped <=
	split, direct-mapped <=
	joint, 2-way set associative
Note: those are Hit Rates, not performance.  There are a bunch of reasons
to keep caches (at least the ones nearest the CPU) direct-mapped when
you can.

The following is a fine paper that analyzes the various tradeoffs in
cache design [rather than just hit rates], is:

	S. Pryzbylski, M. Horowitz, J. Hennessy, "Performance Tradeoffs
	in Cache Design", Proc. 15th Annual Symposium on Computer
	Architecture, May 30 - June 2, 1988, Honolulu, Hawaii.
	(Computer Architecture News 16, 2(May 1988), 290-298.
	
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash at mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086