Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch
Subject: Re: Re: Cache Revisited
Message-ID: <1598@peora.UUCP>
Date: Mon, 9-Sep-85 08:08:38 EDT
Article-I.D.: peora.1598
Posted: Mon Sep  9 08:08:38 1985
Date-Received: Wed, 11-Sep-85 05:34:00 EDT
References: <170@mips.UUCP> <455@mtxinu.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 25

> With this ultimate machine/compiler combination it seems intuitively
> that a data cache would then be a *bad* idea, since having a cache
> can't be faster than an uncached memory reference ...

See, what you have here is a matter of working at a problem from two different
ends.  The example of the compiler that used a large set of registers and
thus produced mostly cache misses is really a compiler that knows about
cache and manages it itself.  The registers are just a cache that's closest
to the processor.

On the other hand, most caches are intended to improve performance with the
assumption that the compilers aren't going to do much of that themselves
(or can't due to the machine's architecture. Or the fact that the same
program is to run on a number of machines of different memory-hierarchy
organizations -- i.e., the compiler that generated good code for a machine
with 250 registers might not work so well (or at all) on a machine with
16 registers;  but for cost reasons it might be desirable for a manufacturer
to produce a machine with cache, and a machine without it, whereas he has
to keep the 250 registers no matter what, if there's code out there that
uses all of them.)
-- 
Shyy-Anzr:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642