Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!ncr-sd!rb-dc1!joe
From: joe@rb-dc1.UUCP (Joe Hollinger)
Newsgroups: comp.arch
Subject: Re: Do RISC Compilers Consider Multipro
Message-ID: <181@rb-dc1.UUCP>
Date: 9 May 88 18:09:53 GMT
References: <620@speedy.mcnc.org> <28200140@urbsdc>
Reply-To: joe@rb-dc1.SanDiego.NCR.COM (Joe Hollinger)
Organization: Gould CSD, San Diego
Lines: 32

In article <28200140@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes:
>
>>Disclaimer: I believe that RISC is the best solution to low order
>>multiprogramming (like my workstation).  But, there does seem to be this
>>application of uniprocessor high order multiprogramming that will not go
>>away (people wanting to put 40 users on a sun 4 and process control
>>with zillions of independent processes).
>
>Agree with your concern - many RISCs, especially those with register 
>windows, have greatly increased context switch penalties.
>
>
>Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
>    aglew@gould.com     	- preferred, if you have MX records
>    aglew@xenurus.gould.com     - if you don't
>    ...!ihnp4!uiucuxc!ccvaxa!aglew  - paths may still be the only way

	This is not always true, however.  The Celerity processor
	maintains multiple register windows.  Each bank of the 
	register window set is associated with a process.  Context
	switching is often faster than more traditional processors.

	Another solution to this problem is flushing and filling the
	register file in the background. Often context switching is
	a laborious enough procedure that this type of operation can
	proceed in parallel with the other housekeeping that has to
	be done.  I don't know of any RISC designs that do this.

	I'm not disagreeing, just pointing out the alternatives.


					Joe Hollinger