Xref: utzoo comp.lang.c:11346 comp.arch:5517 Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!mit-eddie!uw-beaver!uw-june!pardo From: pardo@june.cs.washington.edu (David Keppel) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Keywords: self-modifying code, generate-and-execute Message-ID: <5297@june.cs.washington.edu> Date: 15 Jul 88 20:12:07 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <33518@yale-celray.yale.UUCP> <1087@ficc.UUCP> Reply-To: pardo@uw-june.UUCP (David Keppel) Organization: U of Washington, Computer Science, Seattle Lines: 42 In article <1087@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >[ Why are two caches (I, D) better than one (I+D)? For a given real-estate, a non-snoopy I-cache will hold more data bits and be faster than a snoopy I-cache. + For a given real-estate, the I-cache hit rate will be better. This makes the average instruction fetch time lower. This may be a win if instruction fetch rate is at all a bottleneck. + For a given cache size, the real-estate can be smaller. This means: + The cache may be cheaper. + The cache may be small-enough to put closer to the instruction register, making it effectively faster. + The logic is simpler and more regular. + Faster design times. + Fewer bugs. + Easier to incorporate into VLSI designs (==faster). + Less logic to drive => faster, less power. + The cache doesn't need to be connected to as many things. + More freedom to place the cache => faster, cheaper. + Less external logic to drive => smaller, faster, cheaper. + Aliasing and data distribution are less of (none) a problem. This lets you build (with much less pain) + Heirarchical cache organizations (faster). + Virtually-addressed caches (faster). I-caches are particularly useful on machines that make heavy use of memory. This includes: + Many high-performance processors. + Shared-memory multiprocessors. The primary problem (that I'm aware of) with non-snoopy I-caches is that you must manually flush the I-cache every time that an instruction is changed. (Strictly speaking, every time you change an I-space address that has been touched since the last cold start). Does that answer your question ?-) ;-D on ( Faster ) Pardo