Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!sun-barr!newstop!pitstop!jwest
From: jwest@pitstop.West.Sun.COM (Jeremy West)
Newsgroups: comp.arch
Subject: Re: Register usage
Message-ID: <693@pitstop.West.Sun.COM>
Date: 31 May 89 19:01:03 GMT
References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> <3427@bd.sei.cmu.edu>
Organization: Sun Microsystems, Mt. View, CA
Lines: 53

In article <3427@bd.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
> 
> This is one of the reasons I don't like
> register-file machines: ALL the registers have to be saved and
> restored across a full context switch, and there are an awful lot
> of them.  Moreover, a hardware instruction isn't much help, since
> the holdup is the actual data copy to and from memory, not the
> instruction fetch.
> 

In SunOS running on SPARC it only saves the register windows that
you have actually used when it does a context switch. This is often all
of them but not allways. You have to fetch instructions to save registers,
and the double-word load/store that SPARC uses reduces the number
of instructions by half. Since this gives some assistance I think the
SPARC architects decided that there wasn't much more to gain from a 
more specialised instruction. 

> For this reason, I think people with hard real-time applications should
> look pretty carefully at context switch costs.

If you're that keen on context switching the fastest thing around
IMHO is the Transputer which does it in 600ns at 20 MHz for a full switch
between two low priority tasks. Of course it effectively has one register
(sort of) and prevents you from leaving things in registers when certain
instrcutions are executed :-}

With SPARC you can partition the register windows so that two or more tasks
have separate sets of register windows. You can then get much faster
context switches between a small number of tasks. In fact to do this
effectively you need to *increase* the number of registers and I think
that some future SPARC chips (aimed specifically at realtime) will
have more.
> 
> Some machines use the same register
> window mechanism to handle interrupts, automatically shifting to
> a new set.  If the interrupt hits you at just the wrong call depth,
> you get an automatic register spill.  So about one-sixth or one-fourth
> of the time, it takes maybe three times as long overall to field the
> interrupt and maybe thirty times as long to reach the first instruction
> of the handler.  Since hard real time people care about predictability
> next only to performance, this gives loads of grief.

SPARC always reserves one register window for taking traps and
interrupts in. For an 8-window system the user code would only get 7 before
having to save to memory. If you divide for two processes then they each get
3 windows for user processes and one for taking traps.

Adrian Cockcroft
Sun Cambridge UK TSE
sun!sunuk!acockcroft

(Borrowing Jerry West's account at Mountain View to get at USENET)