Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!alberta!ers!teletron!andrew
From: andrew@teletron.UUCP (Andrew Scott)
Newsgroups: comp.lang.forth
Subject: Re: Multi-user Forth
Message-ID: <93@teletron.UUCP>
Date: Thu, 20-Aug-87 11:43:12 EDT
Article-I.D.: teletron.93
Posted: Thu Aug 20 11:43:12 1987
Date-Received: Sat, 22-Aug-87 11:46:51 EDT
References: <9.2122EF36@circle.UUCP>
Organization: TeleTronic Communications Ltd., Edmonton, Alta.
Lines: 29
Summary: Multi TASKING (not Multi User)

In article <9.2122EF36@circle.UUCP>, rat@circle.UUCP (David Douthitt) writes:
> I would think that task-switching during NEXT would create too high of an 
> overhead. Seems to me that switching during : or ; would be more 
> reasonable.  However, I would still prefer PAUSE and similar for more 
> control.

There must be some misunderstanding of my explanation of task switching
during NEXT which I described in a previous posting.  We don't switch at
every NEXT (which would be incredibly inefficient), only when we want to.
Normal PAUSE is still used to relenquish control to another process, however
we can patch NEXT to perform a PAUSEish task switch when special situations
arise.  For example, should some active task fail to relenquish control through
PAUSE for any reason, a clock interrupt could limit a time slice to some
maximum value and force a PAUSE.  Also, this mechanism could be used to
synchronize some task with an external interrupt.  NEXT is a more convenient
place to perform the task switch than : or ; because it will be executed
much sooner.  If NEXT is implemented as an indirect call (e.g. jsr (a0), where
the a0 register holds the address to NEXT), the interrupt code merely has to
patch the register with the task switching routine's address.  This code can
restore the register to point to NEXT when it's finished the task switch.

As for concerns (expressed by some others) that this technique would be
impractical when dealing with disk buffers etc., I never claimed that this
was a good technique in a multi-USER environment, but a multi-TASKING
environment.  There is a difference!  FORTH is great for real-time systems,
and working with interrupts is a must.  This technique is an easy way to
interface processor interrupts with FORTH tasks.

	Andrew