Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!bionet!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: <16054@agate.BERKELEY.EDU>
Date: 27 Oct 88 02:08:06 GMT
References: <156@gloom.UUCP> <310@lynx.zyx.SE> <332@pvab.UUCP> <15964@agate.BERKELEY.EDU> <23367@amdcad.AMD.COM> <16003@agate.BERKELEY.EDU> <469@oracle.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: matloff@iris.ucdavis.edu (Norm Matloff)
Organization: EECS, UC Davis
Lines: 21

In article <469@oracle.UUCP> csimmons@oracle.UUCP (Charles Simmons) writes:
*In article <16003@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:
*>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.

*If I remember the arguments from MIPS correctly (want to help me out
*John?), there's a stronger objection to multiple-window-register-files.
*I think it's something to the effect that register-windows cause the
*load/store access time to be slower.  I think there also may be some
*argument that a good compiler makes multiple-windows relatively
*unnecessary.

A compiler which automatically inlines procedure calls might be able
to do what you are saying.  However, there may be some unpleasant
side effects, depending on the language.  Actually, one of my grad
students in making a thesis out of this, so I'll try to report more
on it later.

   Norm