Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!bizet.Berkeley.EDU!matloff
From: matloff@bizet.Berkeley.EDU (Norman Matloff)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (was The NeXT problem)
Message-ID: <16003@agate.BERKELEY.EDU>
Date: 25 Oct 88 23:18:54 GMT
Article-I.D.: agate.16003
References: <156@gloom.UUCP> <310@lynx.zyx.SE> <332@pvab.UUCP> <15964@agate.BERKELEY.EDU> <23367@amdcad.AMD.COM>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: matloff@iris.ucdavis.edu (Norm Matloff)
Organization: EECS, UC Davis
Lines: 18

In article <23367@amdcad.AMD.COM> tim@crackle.amd.com (Tim Olson) writes:

>Actually, the register saving is more likely to be on the order of 10 to
>20 microseconds (order of magnitude less than the 0.1 msec you suggest). 
>Comparing 100 context-switches per second to 350,000 procedure calls per
>second, it isn't hard to see where to concentrate your optimization
>efforts...

My computation was a conservative one, assuming (e.g.) the slow 400 ns
cycle time on RISC I, and taking into account that LOAD/STOREs take an
extra cycle.

But the point is, and you seem to agree, that the often-voiced (and
recently brought up in comp.arch) claim that context switches would
make multiple-window-register-file-based RISC's unsuitable for
timeshare applications is just simply not borne out by the data.

  Norm