Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: Do RISC Compilers Consider Multipro
Message-ID: <28200140@urbsdc>
Date: 5 May 88 04:31:00 GMT
References: <620@speedy.mcnc.org>
Lines: 37
Nf-ID: #R:speedy.mcnc.org:620:urbsdc:28200140:000:1932
Nf-From: urbsdc.Urbana.Gould.COM!aglew    May  4 23:31:00 1988


>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.

May I point out, though, that increased machine state is less characteristic
of the MIPS line of RISC processors, typically with no more than 32 registers?

TLB adds no state if you are willing to do without virtual memory, which many
RT applications do (certainly, they don't want paging). However, memory mapping
is nice for improving reliability by preventing processes from stepping on each
other - since mapping is often the only memory protection mechanism provided.
    Hey, are there any segment oriented MMUs out there for RT applications
- ones that don't necessarily translate addresses, but that provide protection
based on process id, and do not require flushes on context switch? Seems to
make sense...

Also may I point out - one reason that many RT applications are structured as
zillions of processes is that the processors they were running on had small 
address spaces - like, 128K. Give them a larger address space, and many RT
applications can be restructured to take advantage of it.



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
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.