Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!mcvax!jack
From: jack@cwi.nl (Jack Jansen)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (was The NeXT problem)
Message-ID: <7681@boring.cwi.nl>
Date: 26 Oct 88 15:00:36 GMT
References: <156@gloom.UUCP> <310@lynx.zyx.SE> <332@pvab.UUCP> <15964@agate.BERKELEY.EDU>
Sender: news@cwi.nl
Organization: AMOEBA project, CWI, Amsterdam
Lines: 31

In article <15964@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:
>
>Based on parameters of Berkelely RISC I or II, the register-saving
>might take on the order of 0.1 msec.  If the quantum size is set to
>be in the range claimed to be typical in the Peterson and Silberschatz
>OS book, i.e. 10 to 100 msec, then we see that the register-saving
>issue for a RISC with lots of regiters has probably been greatly
>overemphasized.
>
>Comments?
>
>   Norm Matloff
Well, 100 usec might be fine for standard unix, it is definitely not
fine for operating systems supporting light-weight threads.

In amoeba, our distributed system, thread-to-thread switch time
is in the order of 20-50usec, and on a fast machine like a R2000
it would probably be down to 5-20usec, not counting the register
save.

What I would like is some help from the architecture, like dirty bits on
groups of registers or something. 
Actually, I'm not *that* familiar with the R2000 (or the other risc
chips, for that matter); do any of them provide a feature for this?

Also, does anyone know  thread switch times for Mach or other systems
that support light-weight threads, and how these would be affected
on machines with large register files?
--
Fight war, not wars			| Jack Jansen, jack@cwi.nl
Destroy power, not people! -- Crass	| (or mcvax!jack)