Software multitasking with the latest instruction set
Seairth
Posts: 2,474
in Propeller 2
Looking at the new instruction set, I notice that the POP instruction appears to affect C/Z. Instead, I suggest that it simply mirror PUSH, in that the top value on STACK is popped into D without changing C/Z. In both cases, I would expect the flags to behave as follows:
Z - Set when POP reaches the bottom of the stack, or PUSH reaches the top of the stackC - When POP or PUSH loops around (to the top or bottom of the stack, respectively)
With this change, I think the CALL/RET/PUSH/POP instructions provide enough functionality to implement a basic cooperative task scheduler. A task would use CALL to relinquish to the scheduler. The scheduler would then use POP to store that task PC/C/Z and PUSH to queue up another task, finally calling RET to jump to the newly queued task.
Further, if the scheduler starts by PUSHing a call to itself on the stack, then a task can signal that it has completed running by calling RET instead of CALL. This would return to the scheduler, which would then POP and get C=1, indicating that the stack was empty (and therefore the task is finished).
While I am on the topic of tasking, there is another simple use case that might be worth looking at: two tasks that cooperatively ping-pong without a scheduler, using a single instruction call. The obvious use case is for an I/O driver to use a single cog (one task for input, one task for output). I thought it might be possible to use the LINK instruction (the first one that's listed), but am unclear if this does what I think it does. Presumably, two tasks could ping-pong by calling "LINK $1F7, $1F7".
All of this would be possible without any additional tasking hardware. So, in the event that the P2 stays as we currently see it, this can be some food for thought...
(p.s. if someone else has already suggested these ideas, I apologize for re-hashing.)
Z - Set when POP reaches the bottom of the stack, or PUSH reaches the top of the stackC - When POP or PUSH loops around (to the top or bottom of the stack, respectively)
With this change, I think the CALL/RET/PUSH/POP instructions provide enough functionality to implement a basic cooperative task scheduler. A task would use CALL to relinquish to the scheduler. The scheduler would then use POP to store that task PC/C/Z and PUSH to queue up another task, finally calling RET to jump to the newly queued task.
Further, if the scheduler starts by PUSHing a call to itself on the stack, then a task can signal that it has completed running by calling RET instead of CALL. This would return to the scheduler, which would then POP and get C=1, indicating that the stack was empty (and therefore the task is finished).
While I am on the topic of tasking, there is another simple use case that might be worth looking at: two tasks that cooperatively ping-pong without a scheduler, using a single instruction call. The obvious use case is for an I/O driver to use a single cog (one task for input, one task for output). I thought it might be possible to use the LINK instruction (the first one that's listed), but am unclear if this does what I think it does. Presumably, two tasks could ping-pong by calling "LINK $1F7, $1F7".
All of this would be possible without any additional tasking hardware. So, in the event that the P2 stays as we currently see it, this can be some food for thought...
(p.s. if someone else has already suggested these ideas, I apologize for re-hashing.)
Comments
" two tasks that cooperatively ping-pong without a scheduler, using a single instruction call. "
Isn't that what we can do already with JMPRET? See the coroutines in FullDuplexSerial for example.
I didn't see a JMPRET in the new instruction set.
The second Link instruction does nearly the same just with other addressing fields:only 4 destination regs, but 20 bit absolute jumpaddress.
On the P1 the JMP, CALL, RET were just variants of the same JMPRET instruction. This is very different on the P2, mainly because the bigger address range for Hubexec.
Andy
I decided I'm not looking at the instruction set until it is cast into silicon and cowering under my soldering iron here.