Path: utzoo!attcan!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Are all RISCs the same?
Message-ID: <6930@aw.sei.cmu.edu>
Date: 8 Sep 88 13:49:50 GMT
References: <58@zeno.MN.ORG> <6903@aw.sei.cmu.edu> <22860@amdcad.AMD.COM>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 63

In article <6903@aw.sei.cmu.edu> firth@bd.sei.cmu.edu I wrote:

 (a) Some have register window systems.  This is a disastrous design
     error that will ultimately doom them.  In particular, the greatly
     increased context-switch time, and the unpredictability in the
     cost of a simple procedure call, make register-window machines
     unsuitable for hard real time applications.

In article <22860@amdcad.AMD.COM> tim@delirun.amd.com (Tim Olson) writes:

  Oh, I suppose that by the same reasoning, any machine with caches,
  virtual memory, or even "page-mode" RAMs is also doomed.  Sigh.  I guess
  it's back to the old TMS9900 architecture with no registers to get in
  the way of that fast context switch and predictability.  ;-)

Yes, machines with caches do indeed cause problems in implementing hard
real time systems; this was brought out in some of the reports of the
MIPS assessment funded by RADC.  Virtual memory is hardly an issue, since
the majority of real time systems do not use it (wisely, in my view).

The TI9900 is indeed an example worth studying.  It had a context switch
time of less than 10usec using early 1970s technology.  Last month I
attended a presentation of a new "RISC" machine with a 20 MHz clock that
couldn't do half as well.

Tim continues:

  How did you measure this "greatly increased context switch time?" There
  is typically a whole lot more going on during a true context switch than
  dumping and restoring register contents.  In addition, many times it is
  interrupt latency, not context switch time, that is important.  Here,
  many "register window RISCS" like the Am29000, SPARC, and 80960 have an
  advantage, in that typically there is a window or reserved register area
  for the interrupt handler to run in without saving *any* registers. 


And in response:

There is NOT a whole lot more going on during a context switch than the
register save and restore.  Setting up the dynamic environment for a
high-level language task normally implies just changing the registers
and restoring any condition codes.  A few machines really blow it by
having a lot of FPU state (eg the MC68000) or by requiring tasks to
use different memory maps (1750a), but on clean machines the major part
of the work is the save and restore of the on-chip registers.  The more
there are, the longer this takes.

The idea of having separate interrupt registers is not new to register
window (or RISC) machines; the PE3200 had them 15 years ago.  I agree that
they are a good idea in some applications.  But what true real time systems
want, in most cases, is interrupts that change the scheduler state, and
hence that are followed by a true context switch.  (The PE3200 does very
badly here).  For most applications, it is not enough just to have fast
"in and out" interrupts; you must also have the fast context switch.

Even without a parallel register set, you can go a long way by reserving a
couple of general registers for the "in and out" interrupt handlers.  If,
of course, your compiler cooperates.  But using the normal register window
for interrupts seems crazy: if the interrupt occurs at the wrong call depth
(1/4 of the time, say) then responding to it will take several times as
long, since 128 (or whatever) registers will be spilled to give it a
window of 32, of which it might use 4.  This is negative leverage with a
vengeance!