Newsgroups: comp.arch
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rice!ariel.rice.edu!preston
From: preston@ariel.rice.edu (Preston Briggs)
Subject: Re: Memory hierarchy
Message-ID: <1991Mar28.152952.18380@rice.edu>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
References: <1998@kuling.UUCP> <2832@shodha.enet.dec.com>
Date: Thu, 28 Mar 91 15:29:52 GMT

devine@shodha.enet.dec.com (Bob Devine) writes:

>The memory hierarchy has, so far, be contained inside the "box"
>and hasn't extended to the disks.
...
>My questions are to the folks with a /dev/crystal_ball: when will
>two level processor caches be here?  When will a storage hierarchy
>be extended to disks (or to ram-disk, or ... etc)?

I think it's happening now.
To the aggressive compiler or programmer, the memory hierarchy
is already extensive

		registers
		cache
		(secondary cache -- does MIPS have one already?)
		TLB
		RAM
		disk

and some efforts are made to block code for each of these levels.
It's the exercise of blocking code (say matrix multiply) for
cache that makes you want lots of set associativity.

It took me a while to think of the TLB as a level in the hierarchy,
but it's true.  Data "in" the TLB can be accessed more quickly than
data outside the TLB.  Same problems with replacement and set associativity
as with cache.  Much faster replacement, though!

Preston Briggs