Spin Task Switching

Dave Hein

The attached object implements multi-tasking in Spin within a single cog. It's an extension of the method pointer concept, where method calls can be performed by manipulating the Spin interpreter's state variables. A task requires it's own stack, just like a separate stack is required if you start up a new Spin cog. A task pointer is used to point to an array of 5 words, which store the Spin state variables pbase, vbase, dbase, dcurr and pcurr.

The test program runs three tasks, which include the main task and two additional task that use their own stacks. I added a simple Sleep routine to show how a task could sleep until a timer completes. A more complete multi-tasking OS could be built around the primitives that are in the test program. However, since this is a cooperative task switching method, tasks would need to perform an OS call periodically to ensure that other tasks are run.

An OS based on a timer tick could be implemented, but it would require modifying the Spin interpreter to force it to run the system thread periodically.

Dave

mindrobots

Very cool , Dave!

I've been thinking about trying this......again, procrastination pays off!!

You know, multitasking is A LOT easier if you have interrupts!! {KIDDING!!!! }

Rick

Dave Hein

A modified Spin interpreter could perform a task switch every 10 msecs by checking CNT before every bytecode fetch. This wouldn't be too hard to implement. Of course, as long a there are spare cogs available it is better to implement tasks in separate cogs like we normally do. However, I can see cases where there there may not be enough cogs, and it might be useful to implement multiple Spin tasks in a single cog.

I think the current Prop is limited more by the 32K hub RAM and speed than it is by the number of cogs, so multi-thread Spin may not make much sense now. However, the Prop 2 will have more hub RAM and higher speed, so multi-thread Spin might make sense on the Prop 2 that may be limited by the number cogs rather than by RAM or processor speed.

Task-aware versions I/O drivers and "waitcnt" could be implemented that would automatically switch to another task while waiting for I/O, or for a timer to expire.

Jorge P

Dave Hein wrote: »

I think the current Prop is limited more by the 32K hub RAM and speed than it is by the number of cogs, so multi-thread Spin may not make much sense now.

Would you be able to add swap space on SDHD media to exceed the 32K limit? I think it is still possible, maybe not logical, to get a real Linux Microkernel running on the prop, especially with the task switching efforts you and others are taking.

Mike Green

@JorgeP,
Yes, YOU could add swap space on SDHD media to exceed the 32K limit. Whether the resulting execution speed would be anything useful is another question. Catalina can already generate code from C source that runs in external static RAM. Again, whether the resulting execution speed is adequate for your task is another question entirely. It's a lot slower than code that runs from hub memory and that, in turn, is substantially slower than native Propeller code.

I'm sure someone, if they really wanted, could implement a Linux microkernel using some kind of cached interpreter. ZOG comes to mind as one example, but other interpreters could be done. It would be really really slow, suitable only for a demonstration project or a teaching tool.