Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!joe!petolino
From: petolino%joe@Sun.COM (Joe Petolino)
Newsgroups: comp.arch
Subject: Re: RISC != real-time control
Message-ID: <50884@sun.uucp>
Date: 26 Apr 88 16:53:04 GMT
References: <1521@pt.cs.cmu.edu>
Sender: news@sun.uucp
Reply-To: petolino@sun.UUCP (Joe Petolino)
Organization: Sun Microsystems, Mountain View
Lines: 29
Keywords: RISC, real-time

>One aspect of RISC processors for real time control that I
>have not seen discussed is the conflict between
>deadline scheduling and the statistical nature of
>RISC performance figures.
>
   .  .  .
>So, what is a real-time control designer to do?

First (as others have pointed out) this problem has more to do with having a
cache than with using any particular type of processor.  RISC processors
complicate this a little by providing opportunities for varying levels of
optimization for a given piece of code.  However, once it's cast into machine
code, execution time (barring memory system effects) is quite predictable
for most processors (either CISC or RISC), and could be determined with a
good simulator.

You could attack the cache problem by clever system design.  A former
employer of mine at one point contemplated building a RISC-based system aimed
at real-time applications.  Our plan was to use a set-associative instruction 
cache, and include a control bit in each cache set (writable by the operating
system) which could 'lock' one of the elements of the set into the cache:  if
the bit was set, that cache block would never get swapped out of the cache
(the rest of the set was still available for 'non-critical' stuff, which
would suffer a higher miss rate due to the reduced cache size).  If you
loaded your response-critical code into the cache, then locked it in, one big
variable went away.  Unfortunately, this system never was built.  Has anyone
else done something like this?

-Joe