Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpcea!hpnmd!hpsrla!brucek From: brucek@hpsrla.HP.COM (Bruce Kleinman) Newsgroups: comp.arch Subject: Re: Harvard Architecure Message-ID: <3460012@hpsrla.HP.COM> Date: 10 Mar 88 20:09:38 GMT References: <8803011911.AA06922@decwrl.dec.com> Organization: HP Network Measurements Div - Santa Rosa, CA Lines: 37 +------- | >Ahh, those massive 256-Byte caches are really going to speed this | > puppy up :-) | | Actually, it will. Remember, the CDC 6600 got a win from an "instruction | stack" of 480 bits ! | | Plus, the two caches access in parallel (versus the one cache of the 68020). | Plus, the caches now take one clock (versus 2 on the 68020). | Plus, the caches now have burst refill (if the board designer supports it, | of course.) | | All in all, a clear improvement. I don't hear any suggestions as to a better | use for the silicon. +------- All in all a clear improvement? Over the '020, perhaps ... The 256-byte data cache is of questionable value, as the miss-rate will be fairly high. I would supply numbers for "fairly high," but I can't seem to find any miss-rate data for caches of smaller than 1 Kbyte. Furthermore, the restricted implementation of the data cache makes it useless in multi-processor systems as well as systems with DMA. The data cache has no facilities for coherency. Solution - disable the data cache or flush, flush away. Suggestions as to a better use for the silicon? OK ... Expand the I-cache. I suspect that loosing the D-cache could make room for a 1 Kbyte I-cache. This would offer honest improvements in almost all systems. High-perf machines can surround the '030 with an hefty sys-cache for increased performance. Memory bandwidth problems, you say? Bring the Harvard architecture out to the pins - which is exactly what Motorola did for the 88000. Bruce Kleinman brucek%hpnmd@hpcea.hp.com -or- ...hplabs!hpnmd!brucek Hewlett Packard - Network Measurements Division Santa Rosa, California