Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!a.cs.uiuc.edu!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: Self-modifying code (and space/
Message-ID: <28200178@urbsdc>
Date: 17 Jul 88 21:35:00 GMT
References: <1744@vaxb.calgary.UUCP>
Lines: 33
Nf-ID: #R:vaxb.calgary.UUCP:1744:urbsdc:28200178:000:1410
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Jul 17 16:35:00 1988


>I have a question:
>
>	Why are an Icache plus a Dcache better than just
>	a big shared cache as big as both?
>
>Peter da Silva  `-_-'  Ferranti International Controls Corporation.

The best data I have seen says that a big shared cache as big as both
would be better - all other things being equal.

The other things include stuff like cycle time, simultaneous access,
line sizes.

For example, with split I/D caches you can have simultaneous access
to both the I and D cache in the same cycle; with a shared cache this
is harder to do.  The I cache doesn't need to have expensive bus
watching circuitry for invalidations.  The I and D caches can be 
located physically closer to where they will be used.  The smaller
the cache, the faster.  An I cache can be optimized for instruction
access, which is much more sequential than data access (this is the 
same type of argument that can lead to a separate cache, or no cache, 
for vectors).


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have MX records
    aglew@xenurus.gould.com     - if you don't
    ...!ihnp4!uiucuxc!ccvaxa!aglew  - paths may still be the only way
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.