Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: How Caches Work
Keywords: adaptive caching, Munin
Message-ID: <31815@ames.arc.nasa.gov>
Date: 13 Sep 89 16:40:38 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>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA - Ames Research Center
Lines: 27

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
alternative which is similar to the option on the CDC 2xx architecture
of having user selectable page sizes.  It could be a very useful feature
to have on a "superscalar" type machine, because you generally don't
want array accesses to be cached.  (On the CDC machines, the OS let
you specify at load time which arrays would go on large pages...)

>Understanding the useability of software-controlled caching is
>a good area for research over the next few years; the answers are not
>yet clear.

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.

  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117