Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!wyse!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (really, context-switching & windows)
Message-ID: <6996@winchester.mips.COM>
Date: 26 Oct 88 04:07:32 GMT
References: <156@gloom.UUCP> <310@lynx.zyx.SE> <332@pvab.UUCP> <15964@agate.BERKELEY.EDU> <23367@amdcad.AMD.COM> <16003@agate.BERKELEY.EDU>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 51

In article <16003@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:
>In article <23367@amdcad.AMD.COM> tim@crackle.amd.com (Tim Olson) 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.

In the following, it must be noted that I am NOT biased in favor of
register windows:

1) It is CLEAR that in a typical UNIX environment, saving/restoring
a SPARC or 29K register file is not, in of itself, particularly important,
compared with typical UNIX scheduling. [Other people got there first
and ran the numbers, I see.]  Of course it costs something, and
even little things add up, but I doubt that this is a dominant effect.

2) It is CLEAR that one MIGHT care about this in
	a) Real-time applications that require guaranteed minimal latency.
	(Note that the real real-time folks would consider anathema
	the solution of keeping one window free and then faulting the
	others in as needed.) [These folks like things like locking
	things in caches, for example.]
	b) Heavy transaction-oriented systems (as Mike Taylor noted);
	these could either be big database systems or
	things like electronic switching systems, which have (effectively)
	numerous small processes.
In both cases, one would have to run the numbers and see, and this is much more
instance-specific than a general UNIX environment.

3) The UNIX kernel can sometimes be painful for register windows (as in
SPARC, but NOT as in the non-window styles of 29K or CRISP) as follows:
	Register window design (as in UCB) used certain kinds of programs
	to create the statistics to support the design. User programs
	often bounce around in a fairly shallow window-count.
	UNIX kernels are worse.  They often zoom up and down 10-12 levels
	very quickly, causing window faults like crazy.  I have to believe
	the SunOS folks have been working hard to tune for this.

4) Finally, issues of multi-user performance on Sun-4s is a completely
separate matter.  As discussed in various USENIX papers, the kind of virtual
cache used in Sun-[34]/2xx needs substantial cache-flushing on
context switch [the UNIX u-area, particularly].  This can be gotten around,
but takes a while to do.  Of course, this effect has nothing at all to
do with register windows.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086