Bob Ammerman wrote:
> My idea is simple this: implement Forth, or a similar threaded
> language. In this case the executable code is a combination of
> interpreted address lists and ordinary machine code. However, instead
> of using the machine stack, Forth uses its own internal data and
> procedural stacks. The pre-emptive multitasking is done in the "Next"
> routine of the Forth interpreter. Note that interrupt level code would
> likely still be written in assembly, and that interrupts could remain
> enabled at all times. The interrupt handlers would just set flags which
> the preemptive scheduler would notice when it next got control.

I thought you were going to use a software call/return stack.  This could be
done with macros for subroutine call and return.  This is less of a cheat
since most of the code executes normally and uses the native instruction
set.  Only call and return are hacked.

Note that I'm not actually advocating this.  Preemptive multitasking is
mostly silly on small resource-constrained systems.  Even cooperative
multitasking is less common than a basic main event loop architecture.

The one place where having a separate thread seems particularly useful is in
dealing with a input stream where the meaning of each byte is dependent on
previous bytes (each byte is not idempotent), such as a protocol where there
are opcodes followed by data dependent on the opcode.  Being able to do
things like a computed GOTO on the opcode is very useful and makes the code
a lot cleaner.  This is essentially using a state machine but using the PC
as the state variable.  However, in that scheme the code needs to appear to
get the next input byte when in reality input bytes come in when they come
in.  This is where a task is useful.  It can check for a new input byte and
yield in a loop until one is available.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist