Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool2.mu.edu!uwm.edu!ogicse!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.141944.5041@athena.cs.uga.edu>
Date: 18 Dec 90 14:19:44 GMT
References: <3042@crdos1.crd.ge.COM> <1990Dec18.082623.16648@kithrup.COM>
Organization: University of Georgia, Athens
Lines: 22

In article <1990Dec18.082623.16648@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
>In article <3042@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
>>  What features should be put into the CPU to improve performance and
>>reduce chip count?
>
>While I don't know that it would reduce chip count, a Good Thing to have
>would be:  MORE REGISTERS!!!!!!
>
>But, of course, it won't happen.  *sigh*
>
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. The only ways out of this require 
lots more hardware and discipline from both the compilers and the programmer.
The first solution involves keeping track of just which registers have been
used during a process and only saving those; lots of very smart (expensive)
hardware, and a need for discipline to keep from using more registers than
really required. The second solution is to provide enough registers so that
each process has its own set which never needs to be swapped; this leads to a
hard limit on the number of processes allowed in the machine at any one time,
OC