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