Wait a sec... shouldn't you be storing those registers in memory and not on the stack? When an interrupt (or a function call for that matter) occurs the PC is pushed onto the stack and it is used to find the return vector. So the stack seems unfeasible for storing task info because it can be easily put out of sync by a function call in one of the tasks. In fact each task should have its own well-defined stack.

You should store these registers in structure(just another well-defined set of RAM memory locations), which you could call the Task Control Block (TCB), analogous to the Process Control Block in PC OS. The stack(s) area begin after the TCBs. Each task should not be allowed to overflow its defined stack area or it will interfere with the stack of another task.

So when the "scheduler" interrupt occurs, what you need to do in your ISR is pop the PC registers off the stack, and store them in your TCB along with the rest of the registers. Then you move the registers from the next TCB into the SP, DPH, DPL etc and push the PC of the next task onto the stack (in the proper order) and do the reti. So the uC starts executing the next task from where it was pre-empted.

As Steve suggested, maybe some register-pushing should be user-defined too, for better performance. So maybe your TCB can have a few registers for user-defined registers. Also you (or the end-user) will need to have properly designed interrupt-handlers, so that no ISR messes up a task or the scheduling...

I know of a similar open source implementation in C... Put a google search on WSMK (World's Smallest Multitasking Kernel).

I once considered doing something similar... but a multitasking kernel is generally overkill for 8-bit uCs. The more you progress, the more complications you will find. Still, it should be a lotta fun doing this! :-)

kundi