Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!ncar!tank!uxc!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: Are all RISCs the same?
Message-ID: <28200198@urbsdc>
Date: 9 Sep 88 16:30:00 GMT
References: <6930@aw.sei.cmu.edu>
Lines: 73
Nf-ID: #R:aw.sei.cmu.edu:6930:urbsdc:28200198:000:4448
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Sep  9 11:30:00 1988


..> I am very much enjoying the discussion about Real Time issues
..> between Firth, Olson, and Garner. 

Firth says that register windows are "a disatrous design error that
will ultimately doom them". I tend to agree with this for RT systems,
and even for conventional systems the evidence is now beginning to 
indicate that good register allocators with large register sets 
can beat register windows.
    But, I don't want to talk about general purpose systems;
let's talk about RT.

>  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).

Having worked in the "soft" real-time market for a bit, listening avidly
to the words of my seniors, I have learned some things. First, there do
exist dedicated real time systems, hard or soft, that do not need the 
things that you want on a conventional system, like caches or virtual
memory. I conjecture that these are mostly to be found in the low end
(eg. factory automation) and high end of the market.
    However, in the middle range of the market, minicomputers and super-minis,
there are a lot of people who want *BOTH* real-time and conventional 
performance. Some do not want it at the same time - eg. a computer site
that "officially" buys a computer to run a simulation that takes over all
the computers on site for maybe a few hours to a day per month -- but also
wants to use the computers that run this dedicated simulation for regular
engineering and office work during the rest of the time.
    Others want RT and conventional capabilities at the same time, because
somebody has to develop on the machine, make reports, etc., and the company
doesn't want the hassle of handling two totally different development and
target systems. Different configurations, perhaps, but even that isn't
always acceptable.
    Finally, there is the class of customers that I see on the horizon,
that wants RT as an aspect of conventional systems - ie. where conventional
is the emphasis, not RT. Eg. "I want RT UNIX on my workstation" - so I can
control sensors scattered through my house, etc. The RT part may be on a
separate processor, or even in a separate box, but I want it seamlessly
integrated with my normal computing environment.
    The first two classes of conventional+RT customers I know to be real;
the second is projection.

In this situation, what we need is not a machine that throws away conventional
features like cache and virtual memory, but one that makes it possible to get
those things out of the way.

>also, the SPARC register windows can be managed differently in a particular
>real-time application:  every other window in SPARC can be marked invalid
>in the privileged Window Invalid Mask register.  this yields
>"number-of-windows/2" 40-register groups, where each group comprises
>32 registers plus 8 trap handler registers dedicated to a real-time task.
>tasks are protected from each other via the Window Invalid Mask.  changing the
>Current Window Pointer accomplishes a process switch among the active groups.
>(of course, processes in this scheme are compiled with a "single, traditional
>register set" model.)

This mode of using register windows is one of the most attractive to the RT 
side of me. Note that the AMD29000 can do it this way too. Ie. you are basically
using the register windows as non-overlapping disjoint register files.
    But then the conventional side of me takes over. Larger register files,
for windows or other, implies slower registers. Is it worthwhile? Probably not.
Disjoint register files at least imply the possibility of powering off some
sections of the file - although I suppose that it could be done for 
register windows. The really big win will come if someone makes a register
file of N sets of M registers, that can turn off or disable or not require
address lines to the inactive N-1 sets, so that the active set of M registers
runs at a speed comparable to that of register file that only has M regs.