Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!mcdphx!udc!neutrino.urbana.mcd.mot.com!dfields
From: dfields@neutrino.urbana.mcd.mot.com (David Fields)
Newsgroups: comp.arch
Subject: Re: Re^2: Macintosh OS
Message-ID: <1280@urbana.mcd.mot.com>
Date: 14 Jun 90 22:32:50 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <4242@darkstar.ucsc.edu>
Sender: netnews@urbana.mcd.mot.com
Reply-To: dfields@urbana.mcd.mot.com
Lines: 34

In article <4242@darkstar.ucsc.edu>, golding@saturn.ucsc.edu (Richard A.
Golding) writes:
|>In article <jdarcy.644899889@zelig> jdarcy@encore.com (Mostly Useless)
writes:
|>>mattly@aldur.sgi.com (James Mattly):
|>>> <James asks us to consider compiler support for adding premption points>
|>>
|>> <jdarcy suggest that the compiler would have a difficult time finding
|>>   appropriate places for preemption with out significant help from the
|>>   application designer>
|>
|>In fact some recent research  has shown just the opposite:  that
|>compile- time assistance is a very *good* thing for operating system
|>design.  The Emerald system (University of Washington) gets a lot of
|>compiler assistance, and gets significant speedup as a result.  More to
|>the point of this newsgroup, the SOAR (Smalltalk on a Risc, UC
|>Berkeley) processor makes assumptions about code behaviour to allow a
|>simpler interrupt and context-switching mechanism.  By only performing
|>context switches at method invocations, things got easier (it's been a
|>couple years since I read Ungar's dissertation so the details are a bit
|>hazy.)  
|>
|>So I think it's rather hasty to say that compiler assists like this
|>are unreasonable... people are actually doing such things.
|>
|>-richard

I haven't read to much about Emerald.  Does it have support for adding
preemption to applications?  Or were you just generalizing jdarcy's
suggestion that compiler support for application preemption would be in
appropriate to mean that ALL compiler assistance to the OS would be evil.
                                        
Dave Fields // Motorola MCD // uiucuxc!udc!dfields //
dfields@urbana.mcd.mot.com