Newsgroups: comp.arch
Path: utzoo!utgpu!jarvis.csri.toronto.edu!ephemeral.ai.toronto.edu!bradb
From: bradb@ai.toronto.edu (Brad Brown)
Subject: Re: RISC & context switches
Message-ID: <89Feb12.125852est.10867@ephemeral.ai.toronto.edu>
Organization: Department of Computer Science, University of Toronto
References: <784@atanasoff.cs.iastate.edu> <7239@june.cs.washington.edu>
Date: Sun, 12 Feb 89 12:58:52 EST

In article <7239@june.cs.washington.edu> robertb@uw-june.UUCP (Robert Bedichek) writes:
>In article <784@atanasoff.cs.iastate.edu> 
>             hascall@atanasoff.cs.iastate.edu (John Hascall) writes:
>> <some lines deleted>
>>
>>  I seem to recall there was (is?) a TI processor which had all of
>>  its registers in memory except 1 register which pointed to
>>  the other registers, so a context switch was just save/restore
>>  that one register.  Could a similar concept be implemented
>>  with all the registers in the chip?

This is not a bad idea if you have the silicon to do it (as other posters
have pointed out.)  Actually it's been used in some designs.  The most
interesting is actually the IBM 8100, a fast transaction processing machine
which is kind of old and has now been discontinued.  

The 8100 had a total of 1024 registers, divided up into banks of 32 registers.
That means 32 processes could each have their own context and you could
switch between processors REALLY fast.

There is a somewhat related problem when you make a subroutine call --
the calling function usually has to save its registers so it gets it's
"context" restored when the function returns.  Machines like MIPS have
made use of their very large number of registers (192?) by having a pointer
to one of the registers that is effectively the base pointer for the
stack of registers that the currently executing function can use.  When
you want to make a function call you just advance the pointer past the
registers that you are using, zap arguments into the registers just
after the pointer, and branch to the function.  (Of course it's more
complicated than that, but you can see where the time savings comes from...)

					(-:  Brad Brown  :-)
					bradb@ai.toronto.edu