Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!tektronix!hplabs!hp-pcd!orstcs!richardt
From: richardt@orstcs.UUCP (richardt)
Newsgroups: net.arch
Subject: Re: Cache revisited
Message-ID: <12200012@orstcs.UUCP>
Date: Mon, 22-Jul-85 22:30:00 EDT
Article-I.D.: orstcs.12200012
Posted: Mon Jul 22 22:30:00 1985
Date-Received: Sun, 28-Jul-85 05:18:20 EDT
References: <5374@fortune.UUCP>
Organization: Oregon State University - Corvallis, OR
Lines: 17
Nf-ID: #R:fortune:-537400:orstcs:12200012:000:1040
Nf-From: orstcs!richardt    Jul 22 18:30:00 1985

I wouldn't know about UNIX, but a cache of the type you're describing
certainly does speed thngs up, if you can run it fast enough.  The '020
internal cache is nice, but there are a number of things it has problems
with:  any loop which relies on a lookup table; any loop which uses a
constant which is in data space because it is constant throughout a run but
changes from run to run; and generally any loop which uses fixed tables in 
data space.  A larger cache could also handle entire control loops instead
of merely operation loops.  For example: the Forth main interprter loop
or editor loop aren't very long.  They are just barely long enough to fall
outside of the '020 cache for example.  with an 8k cache, you could probably
make an interpreter or any other reasonably complex interactive program
run with a very high hit ratio.

You'll note I haven't given any figures.  That's because I haven't gotten
my own design completed or up and running yet.
					orstcs!richardt
"Is there an Assembly Language Programmer in the house?"