Xref: utzoo comp.lang.c:11572 comp.arch:5800
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!nuke!oconnor
From: oconnor@nuke.steinmetz (Dennis M. O'Connor)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <11689@steinmetz.ge.com>
Date: 29 Jul 88 20:20:08 GMT
References: <1087@ficc.UUCP>
Sender: news@steinmetz.ge.com
Reply-To: oconnor%sungod@steinmetz.UUCP
Organization: GE Corporate R&D Center
Lines: 22

An article by ge@hobbit.sci.kun.nl (Ge' Weijers) says:
] From article <1087@ficc.UUCP>, by peter@ficc.UUCP (Peter da Silva):
] > 	Why are an Icache plus a Dcache better than just
] > 	a big shared cache as big as both?
] 
] The answer is bandwidth. The CPU does not have to stop filling
] the instruction pipeline when it accesses/writes data.
] -- 
] Ge' Weijers, Informatics dept., Nijmegen University, the Netherlands

This is indeed part of the answer. The other part is that
instruction-fetch behavior is much simpler and more predictable
than operand fetch, and that I-caches don't need to be
written-through, allowing an isolated I-cache to be simpler
and more effective than a combined operand/instruction cache.

Specilized I-caches, like a Branch-Target cache combined with pre-fetch,
can produce effective hit rates of 99%+ with only a few thousand
bits of storage. Operand caches can't do anywhere near this well.
--
 Dennis O'Connor   oconnor%sungod@steinmetz.UUCP  ARPA: OCONNORDM@ge-crd.arpa
    "Never confuse USENET with something that matters, like PIZZA."