Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!cernvax!chx400!bernina!neptune!inf.ethz.ch!brandis
From: brandis@inf.ethz.ch (Marc Brandis)
Newsgroups: comp.arch
Subject: Re: Let's pretend
Keywords: Intel, 586, windows
Message-ID: <18993@neptune.inf.ethz.ch>
Date: 19 Dec 90 08:13:45 GMT
References: <3042@crdos1.crd.ge.COM> <1990Dec18.082623.16648@kithrup.COM> <1990Dec18.141944.5041@athena.cs.uga.edu>
Sender: news@neptune.inf.ethz.ch
Reply-To: brandis@inf.ethz.ch (Marc Brandis)
Organization: Departement Informatik, ETH, Zurich
Lines: 41

In article <1990Dec18.141944.5041@athena.cs.uga.edu> is@athena.cs.uga.edu ( Bob Stearns) writes:
>>
>>While I don't know that it would reduce chip count, a Good Thing to have
>>would be:  MORE REGISTERS!!!!!!
>>
>>
>While more registers sound like motherhood and apple pie, in the UNIX world
>they can be a distinct losing proposition. The commonest service provided by
>the kernel is a state switch between processes. The more registers, the longer
>this state switch must necessarily take.  ...

Of course, a process switch takes longer when you have more registers to save.
However, when you look at the typical process switch times in UNIX, you will
see that the register saving part is not a dominating part. UNIX process 
switch times are in the millisecond area, while the time required to save
registers is in the microsecond area. How much will it make your process switch
time longer when you would have 32 registers in the 386 instead of 8? 24 loads
and 24 stores, or something between 100 and 200 processor cycles, which is 
between 4 and 8 microseconds on a 25 MHz machine. This accounts for around one
percent of the process switch time (or less, I do not have exact numbers for
386 implementations of UNIX).

Now look at the alternative, which is to let the application do more memory
references because it cannot keep enough information in the registers. 
When you look at recent papers about computer architecture or compiler 
construction, you will see that a larger register file is able to reduce the
number of memory references a lot. Between two process switches, you are very
likely to save more than 50 references when having a larger register file,
thus making the machine faster. 

I understand that there are applications in embedded systems where a very fast
task switch is important, and where the work done per task switch is low. In
these cases a processor context as small as possible is the right choice.
However, you do not want to run such a high-overhead process switch like in
UNIX on such a system.


Marc-Michael Brandis
Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland
email: brandis@inf.ethz.ch