Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!abc
From: abc@brl-tgr.ARPA (Brint Cooper )
Newsgroups: net.arch
Subject: Re: cache designs
Message-ID: <5968@brl-tgr.ARPA>
Date: Tue, 20-Nov-84 15:56:24 EST
Article-I.D.: brl-tgr.5968
Posted: Tue Nov 20 15:56:24 1984
Date-Received: Thu, 22-Nov-84 05:56:39 EST
References: <2571@dartvax.UUCP>
Distribution: net
Organization: Ballistic Research Lab
Lines: 58

> 
> All the cacheing schemes I have ever heard of seem to work on a
> demand paged basis.  When a piece of information is asked for,
> it is sucked into the cache, replacing the least recently used
> piece of data in the cache. 

Not exactly.  There is usually an entire "block" of data in the cache.  	
> 
> One problem with this approach is that when the processor realizes
> that a desired piece of data is not in cache, then the processor must
> wait until the data can be read into cache.  

But only a few microseconds.  The time is so short, the OS isn't even
aware of it.
...
> 
> Now suppose we had a cache that was much more under a programmer's control.
> To be concrete, suppose we have a cache of say, 32 elements each containing
> 32 words.  And suppose our processor has a load cache instruction with
> syntax:
> 
>     load cache <cache address> <memory address>
> 
> When this instruction was executed, the instruction execution processor
> would quickly tell the cache processor to pick up some data from memory.
> Now, while the cache processor is picking up the data, the instruction
> processor continues executing instructions which are already in cache.
> 
> Using this instruction, I could imagine a very careful programmer helping
> the system to obtain cache hit rates of at least 90%. 
> 
> So maybe someone out there can tell me about interesting cache designs,
> or tell me why a cache such I have described wouldn't work... 

It probably would work, but it isn't needed.  Further, this is the sort
of drudgery from which programmers must be liberated.

Cache memory is based upon the "principal of locality," which sort of
means that the next memory location to be referenced by the program is
probably quite close to the last one referenced.  Therefore, with a
"reasonable" cache size and a fast cache, high "hit ratios" should be
possible.  The exact numbers, of course, depend upon the probram being
run and the design parameters.


*** REPLACE THIS LINE WITH YOUR MESSAGE ***
Brint

(301) 278-6883    AV:  283-6883     FTS: 939-6883

ArpaNet:  abc@brl
UUCP:     ...!{decvax,cbosgd}!brl-bmd!abc
Postal:

  Dr Brinton Cooper
  U.S. Army Ballistic Research Laboratory
  Attn: AMXBR-SECAD (Cooper)
  Aberdeen Proving Ground, Md  21005