Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!claris!jazzman
From: jazzman@claris.com (Sydney R. Polk)
Newsgroups: comp.sys.apple2
Subject: Re: apple // and multitasking, perfect together! (!!!!!!!!!!)
Message-ID: <10920@claris.com>
Date: 8 Mar 90 23:51:36 GMT
References: <7377@latcs1.oz.au>
Organization: Claris Corporation, Santa Clara CA
Lines: 29

From article <7377@latcs1.oz.au>, by stephens@latcs1.oz.au (Philip J Stephens):
> In article <17861@boulder.Colorado.EDU>, Christopher Hassell writes:
>> 
>> 	For timed interrupts:
>> 
>> 		One can compile around a break-point-table <literally> which
>> 		gives positions in code where break-instructions can be quickly
>> 		put and where the code can be restored after control has been 
>> 		handed to the kernel. <for re-entry>
> 
>    An intriguing idea.  This is ridiculously easy to implement: All the OS
> needs to do is save the registers (and possibly the interrupt address and
> status register from the stack), then restore everything before JMPing back
> into the program.  Very good idea.  I had never thought of using BRK
> instructions for that purpose.
>    For even more simplicity, the compiler really only needs to insert BRK
> instructions after every _atomic_ statement (not compound ones) of a high
> level language.  This ought to provide reasonable response time, and will
> minimize the amount of context saving that is needed to switch processes.

This will also drastically slow your code down.  Compiled code on the II
is slow even with a good compiler.


-- 
Syd Polk           | Wherever you go, there you are.
jazzman@claris.com | Let the music be your light.
GO 'STROS!         | These opinions are mine.  Any resemblence to other
GO RICE!           |  opinions, real or fictitious, is purely coincidence.