Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!emory!athena.cs.uga.edu!is
From: is@athena.cs.uga.edu ( Bob Stearns)
Newsgroups: comp.arch
Subject: Re: Let's pretend
Keywords: Intel, 586, windows
Message-ID: <1990Dec18.202842.11771@athena.cs.uga.edu>
Date: 18 Dec 90 20:28:42 GMT
References: <1990Dec18.082623.16648@kithrup.COM> <1990Dec18.141944.5041@athena.cs.uga.edu> <1990Dec18.173039.882@kithrup.COM>
Organization: University of Georgia, Athens
Lines: 12

Not only have I taken the OS courses, I have written, mucked about in and
generally been involved in more OS type work for various architectures than
most people even know exist. Note that when I read "more registers" I think
in terms of machines like the CYBER 205 with its 256 64bit registers or even
larger sets. Yes, when the register count is a measly 8-32 32bit registers 
the save/restore overhead is fairly small, although there is also the call
versus interrupt penalty, depending upon who must save/restore registers 
during a call/return sequence.  The rest of the state is small compared to
the 8K bits of registers I was considering, and the choice of next process to
schedule should have been already taken care of by the process list maintenance
routines using something like a heap by priority/time so selecting the next one
should be a very short algorithm. See Sedgewick on the subject.