Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Real Time/Cache
Message-ID: <17999@cbmvax.commodore.com>
Date: 24 Jan 91 02:37:51 GMT
References: <11190@pt.cs.cmu.edu> <90331.001007DXB132@psuvm.psu.edu> <11228@pt.cs.cmu.edu>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 25

In article <11228@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>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.

	Instead of making on-chip cache, for real-time work on-chip FAST
memory may well be better, especially if it's managed properly.  The new
AT&T DSP uses this sort of memory (the 3210 has 2K of on-chip multi-port
SRAM).

	The cache does nothing for you in a realtime application since you
have to assume worst-case anyways (well, not nothing, but not far from it -
non-realtime tasks on the same machine might get an advantage).

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)