Re: [colorforth] multitasking
- Subject: Re: [colorforth] multitasking
- From: Mark Slicker <maslicke@xxxxxxxxxxx>
- Date: Fri, 15 Oct 2004 18:19:12 -0400 (EDT)
On Fri, 15 Oct 2004, Jeff Fox wrote:
> > I was curious about a couple things.
> >
> > On a stack machine, how is multitasking acheived? 'pause' in colorForth
> > will exchange between two sets of stacks by changing the stack pointers in
> > the pentium registers. That is not an option for a stack machine.
>
> Your definition of stack machine is very narrow. Many stack machines
> have had the ability to exchange registers inluding stack pointers.
> Some have even had alternate sets of registers so that single cycle
> is all that is needed to change all the registers including the
> stack pointers.
>
> Now Chuck's VLSI stack machines have had neither stack pointers
> into memory nor automatic spill/fill mechanisms like those he
> used on Sh-Boom. So perhaps you mean't the VLSI chips that
> Mr. Moore has done rather than the generic term stack machine.
I wasn't trying to define stack machines, but yes I'm refering to those
machines that have a hardware stack (what is the right term?), not a stack
implemented in memory.
>
> Multitasking also does not have one single definition that fits
> all. What we call multitasking in Forth is generally called
> multithreading by most people becuase tasks generally share
> the same memory space. So we have heavywiight, medium and
> lightweight multi-tasking (multithreading implementations
> that share/co-ordinate different amounts of resources.
>
> Medium is exchange stack pointers and user pointer and/or
> any stack items cached or stored in on-chip registers.
> Heavyweight, like we had in 4OS also passed ownership of
> resources. Tasked owned allocated dynamic memory, files,
> i/o devices, and used semiphores and channels to symchronize
> tasks. Still compared to most systems it had a very small
> and very fast multitasker. Lightweight exchanges a minimum
> of registers and may require that the tasks clean up stack
> use themselves at pause.
How was ownership passed in 4OS? With regard to stacks did 4OS swap
stack pointers, or did it use another mechanism?
I am also interested, what kinds of tasks were used in 4OS? Is there any
greater detail available on the design of 4OS?
>
> But in addition to many ways to implement multi-tasking
> in software on most any and all hardware there is the
> issue that stack macines may have custom hardware. They
> can use any hardware trick that they want to make faster
> or easier multitasking if that is important.
Did the i21 have such capability?
>
> > Is the second task in colorForth really needed?
>
> It is for many of the things in colorfort to work the
> way they do. You wouldn't see source blocks and memory
> dumps being updated in the background if their was not
> that background processing going on. Is it important to
> you? Maybe not.
I guess I mean the actual multitasking code and the seperate stacks. The
loop which waits for keys contains a builtin pause which switches to
the second task (the display task) which causes an update in the display.
If the display function can clean up after itself, the keyboard loop
itself could call the display function as an ordinary Forth word. I
speculate that Chuck must have some other use for the second set of
stacks which is not seen in his publicly available code.
>
> > It seems the display can
> > clean up after itself, perhaps if you wanted to break the rendering into
> > chunks a 'pause' might be useful, the same effect could achieved by a
> > state variable however.
>
> Could. Many things are possible. It could render over a network
> connection to a remote virtual monitor etc. Everything in any
> given version of colorforth does not have to be the way it is.
>
> Best Wishes
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com