Path: utzoo!mnetor!uunet!husc6!im4u!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.arch
Subject: Re: RISC != real-time control
Message-ID: <4921@bloom-beacon.MIT.EDU>
Date: 27 Apr 88 19:41:10 GMT
References: <1521@pt.cs.cmu.edu> <28200135@urbsdc>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Organization: Massachusetts Institute of Technology
Lines: 29

Problems like this have already cropped up in the modem field, where
you have RISC-like processors (e.g. TMS32020) which require very fast
memory running code which has to run every sample time, and then a lot
of random code to control the front panel, RS232, MNP, and other
random piddling stuff. The solution until now was to use an 8 bit
micro (sometimes a 68000) to do the piddling stuff that took up 80-90%
of the code volume, and a signal processing micro to do the fast
stuff, and give them each their own slow and fast memory,
respectively.

Things have changed. It is now possible to get at least one of these
chips (I think it's the 32020) to do wait states on memory, and
someone (I don't remember who) has now put their MNP implementation
and a few other things on this processor, in slow ROM, while their
signal processing code runs in fast (20ns?) RAM.  It takes a lot more
ROM space than an eight bit micro (simple, fixed-length (32 bit?)
instructions, poor handling of anything but integer multiplies and
accumulates) , but you still end up with fewer chips, lower cost, and
a negligible load added to the signal processor. 

The interesting thing to notice is that there is no need for fast
memory to be used as a cache in an embedded application. Just load
your time-critical code into fast memory, and your random stuff into
slow memory. If the time-critical part of the code is huge, then a
cache wouldn't help anyway. 


				Peter Desnoyers
				peter@athena.mit.edu