Xref: utzoo comp.lang.c:11362 comp.arch:5529
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Summary: sometimes you win and...
Message-ID: <478@proxftl.UUCP>
Date: 16 Jul 88 13:44:51 GMT
References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <60175@sun.uucp>
Organization: Proximity Technology, Ft. Lauderdale
Lines: 15

In article <60175@sun.uucp>, petolino%joe@Sun.COM (Joe Petolino) writes:
> >>    Why are an Icache plus a Dcache better than just
> >>    a big shared cache as big as both?
> >
> >In terms of hit/miss ratios, a unified cache is clearly better.
>
> I beg to differ...
>                                  ...Take this with a grain of NaCl: we only
> tried a few test programs, and each was small enough to fit into the cache.

Another relevant point about separate caches is this:
instructions and data have different access patterns.  A cache
designed for the one is not necessarily going to be right for the
other; a cache designed for both may not do as well as the
separate ones.  So this possibility has to be balanced against
the general benefit of having a larger pool to work with.