Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!fas.ri.cmu.edu!schmitz
From: schmitz@fas.ri.cmu.edu (Donald Schmitz)
Newsgroups: comp.arch
Subject: Re: RISC & context switches
Message-ID: <4274@pt.cs.cmu.edu>
Date: 14 Feb 89 15:06:20 GMT
References: <784@atanasoff.cs.iastate.edu> <7239@june.cs.washington.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 44

In article Robert Bedichek writes:
>In article John Hascall writes:
>> <proposal to have register banks which switch at context switch>
>>
>>  It seems to me that such a scheme would take little extra hardware
>>  (other than the extra registers).  I just pulled the number 16 out
>>  of the air, any power of 2 would be as easily implemented--perhaps
>>  enough that on a workstation most or all of the processes could
>>  have a "real-time" slot.
>
>Yes, but the extra hardware for the registers takes a lot of silicon
>area!  Some Xerox machines had such a scheme.  They had something like
>8 register banks and could do a context switch in a few cycles.  A
>large semiconductor company copied this idea in an IO processor that I
>think will never see the light of day.
>
>>A hair-brained scheme or what?

A similar thread went around a year ago, and I came up with the idea of CPUs
with externally addressable register/state files, plus a "scheduling CPU".
The "scheduler" would make the CPUs context switch by exterally halting
them, dumping/updating their register file via a DMA or block xfer operation
to fast memory used as a PCB cache (via the hardware interface to the
register file), and then restarting them.

The real win is not so much the reduced context switch time, but the ability
to run the scheduling process on a dedicated CPU in parallel with the "real"
processes.  The extra cycles available for scheduling can (hopefully) be
used for more sophisticated scheduling algorithms.  This would be a real win
in a multi CPU system, as "real" processes could be scheduled to avoid
conflicts for system resources, such as main memory bandwidth and disk
accesses.  The hardware cost of this is an extra data/address path to the
register file, plus some additional multiplexing of the chip pins - not
insignificant in a really high perf CPU but much less costly than multiple
register files.  If you don't want to build mutant chips, you can do a
similar thing with conventional processors, shared memory, interrupts and
software, without quite the savings in the raw context switch time (but
still a win in scheduling time and hopefully a big win in overall
utilization).

Anyway, I got 2 or 3 responses from places working on such systems, although
I still haven't seen one released.

Don Schmitz	(schmitz@fas.ri.cmu.edu)
--