Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Real Time/Cache
Message-ID: <11228@pt.cs.cmu.edu>
Date: 29 Nov 90 02:35:46 GMT
References: <11190@pt.cs.cmu.edu> <90331.001007DXB132@psuvm.psu.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 27

In article <90331.001007DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>Perhaps it would be better in many cases to forget about the cache, and
>simply put some fast static RAM in the memory map, to be used for time-
>critical routines and data storage. The not-so-critical routines would be
>placed in relatively slow memory (presumably you are thinking about very
>large chunks of software else a pure static RAM approach is simpler and
>just as cheap. Of course my idea of very large is 8K or so :-))

I did the same, once: we had 768 words of 100 ns SRAM and 64 KW of
core (yes, core). The SRAM was enough to hold a few interrupt
handlers, and all of the important inner loops (eg. the FFT).  We
could keep the data in core, since we had a scoreboarded load-
multiple and store-multiple.

I'm not sure that the SRAM idea completely overshadows the real-time-
cache idea. With some current machines, one can put memory SRAM in
parallel with the cache SRAM, or in place of it. But there's a big
trend to on-chip cache, and external SRAM is surely going to be
slower than that. (Aside from an extra clock or two of access, there
is often a bus width difference.) So, although uncached references
out to SRAM are faster than uncached references out to DRAM, we're
still looking at the cache giving better average-case performance.

The performance cost of the segmented cache scheme isn't clear to me,
so I'd still like comments on it.
-- 
Don		D.C.Lindsay