>      To continue the discussion, you might present a low-latency, pre-
>      emptive, context switch using neither a h/w nor s/w stack...

Well, there's always the RETLW approach I presented earlier, which isn't
true context-switching, but is in many cases useful and FAST.  Otherwise,
context-switching requires that the states of the two (or more) tasks be
stored independently.  While stacks are a good way to do this, an altern-
ative is to use direct-mapped memory/registers instead.  Since PIC-based
C compilers almost universally use direct-mapped memory for local variables
(generally using knowlege of call patterns to overlay variables), all that
needs to happen to allow context switching of tasks' variables is to ensure
that the compiler does not overlay variables for procedures that will be run
concurrently.

The only other issue that comes up, then, is support for subroutine calls.
Here, too, it's possible to emulate CCS' PCB compiler (for the 5x PIC's)
which stores return addresses as local variables (there's then a jump table
of all the "real" return addresses).  A subroutine call would then look
like this:

        ; Okay, I want to call FOO here
        movlw   JUMP99
        goto    FOO
DEST99:
        ; Code continues...

        ; Okay, here's procedure FOO
        movwf   foo_ret
        ; Okay, now I do the stuff in foo.  Then...
        movf    foo_ret,w
        movwf   PCL     ; Assuming high-order bits point to the jump table

        ; And here's the jump table:
        ...
        ...
JUMP99: goto    DEST99
        ...
        ...

If the code is set up like this, then context-switching is a piece of cake
(of course, a call/return now takes a total of 9 cycles rather than 4).  If
there are two tasks, ALPHA and BETA, then the task-gates simply look like
this (they're "called" the same way as FOO above)

ALPHAGATE:
        movwf   beta_ret
        movf    alpha_ret,w
        movwf   PCL

BETAGATE:
        movwf   alpha_ret
        movf    beta_ret,w
        movwf   PCL

A context switch then takes only a total of nine cycles to complete--this
is even better than my RETLW-based approach, which needs ten if a jump table
is used.

While a stack-based context-switch is necessary--at least for the execution
stack--if the different processes are allowed to CALL functions arbitrarily,
using a fixed-memory allocation scheme is often possible and in some cases
may work very well.