Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!atanasoff!hascall
From: hascall@atanasoff.cs.iastate.edu (John Hascall)
Newsgroups: comp.arch
Subject: Re: RISC & context switches
Message-ID: <792@atanasoff.cs.iastate.edu>
Date: 13 Feb 89 14:33:00 GMT
References: <784@atanasoff.cs.iastate.edu> <7239@june.cs.washington.edu> <89Feb12.125852est.10867@ephemeral.ai.toronto.edu>
Reply-To: hascall@atanasoff.cs.iastate.edu (John Hascall)
Organization: Iowa State U. Computer Science Department, Ames, IA
Lines: 25

In article <89Feb12.125852est.10867@ephemeral.ai.toronto.edu> bradb@ai.toronto.edu (Brad Brown) writes:
>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>

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

   This was part of my question... I take it, at context switch the MIPS
   processor has to save and restore all those registers (at least as
   far "up" as the "topmost" register in use--potentially all of them).
   Doesn't that mean roughly 400 memory accesses (assuming 192 is correct),
   all at once--just the sort of thing RISC is supposed to avoid?

   What effect (if any) does this have on the suitability of these processors
   for "real-time" systems?


   John Hascall
   ISU Comp Center