Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!ginosko!husc6!rice!titan!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.arch
Subject: Re: How Caches Work
Keywords: adaptive caching, Munin
Message-ID: <1184@brazos.Rice.edu>
Date: 13 Sep 89 23:02:24 GMT
References: <21936@cup.portal.com> <1082@cernvax.UUCP> <16306@watdragon.waterloo.edu> <RANG.89Sep10184900@derby.cs.wisc.edu> <8399@boring.cwi.nl> <3989@phri.UUCP> <1174@brazos.Rice.edu> <27445@winchester.mips.COM> <31815@ames.arc.nasa.gov>
Sender: root@rice.edu
Reply-To: preston@titan.rice.edu (Preston Briggs)
Organization: Rice University, Houston
Lines: 33

In article <31815@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>In article <27445@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>
>>MIPS R3000s use one of the address bits to distinguish between
>>cached/nocached access for the "unmapped" part of the kernel address
>>space, and actually uses this in various ways.  For example, you can
>
>It would appear that a "general" form of this would allow arbitrary
>memory sections to be cache/nocache.  This is an interesting


>Since there are times when you *do* want array accesses to be cached,
>this might be a case for having two different load instructions, one
>cached and one not cached.  That would allow the compiler and/or user
>to choose at any moment what the optimal choice is for that load.

I think you're right.  The i860 allows both cached and non-cached loads.
It would sometimes be nice if they allowed a variable line size
(small, to prevent loading extra unneeded data, 
 or large, to preload data that will be needed soon.)
A fetch-block-to-cache instruction might actually be what's wanted.

I expect compiler people will want more and more control over the cache
in the future.  Current hardware management will continue
to be demanded for un-cache-optimized code.

An analogy might be stack machines vs. register machines.
Without good register allocation, stack machines with top of
stack caching are pretty good.  With good register allocation,
we can do better with by explicitely controlling the registers.

Preston Briggs
preston@titan.rice.edu