I am actually quite concerned that all the multi-tasking and multi-threading additions may introduce bugs into the non-tasking/threading modes. When it was simple I was not concerned with this. As long as the basic modes worked, we could live with any problems and work around them. I am not so sure anymore.
Don't worry - this isn't like some software nightmare. Hardware is much more straightforward and bugs are rarely subtle. I'm more concerned that we'll have the silicon area that we need and that the power consumption isn't too high.
Having the ability for the scheduler task to choose to increment or not depending on the way the YIELD/TSTALL operation was called is useful. For example, if you used it as a dynamic breakpoint which you inserted into the user task code, you would want to be able to patch the original code back and return to the original PC (so no increment required there), but if it was used as a system call like PUTCH or as a true YIELD operation, you would want to return to the next intruction after it and then need the increment. The scheduler task now has full control over what it does in response to the user task if we give it an INCPC instruction which also avoids reading/writing the WIDE holding its task state each time.
As to some earlier comments know that I fully support these multi-tasking, multi-threading efforts as I see this as adding significant extra capabilities to the P2 which only increases its potential market. But I don't think this P2 development is necessarily a marketing driven project, it is basically engineering driven primarily from Chip's interests/desires and bouncing ideas off people like us. That is just how it is working out for better or worse.
No one can possibly know all the forecast sales numbers with or without this or that feature in the device. Sure P2 won't be competing with an ARM for power and price etc, but what if it could now open up new or unforeseen applications that could really benefit from P2's hard real-time I/O, video, signal processing capabilities etc and now allow larger/richer control applications and existing C code or people used to RTOS etc to now come on over to the P2 with relative ease. That could really open P2 up to a lot of things. To me it would seem like a big effort try to just basically recreate a faster P1 and hard limit to 8 COGs again albeit at 200MHz or so, and thankfully that is not the case here. If it were then you might start to restrict yourself to the same customers/market as P1 already has. That is where all this tasking etc will help expand the target market for P2 and let new possibilities arise. The best thing is it doesn't need to be used if it seems foreign and some of the existing P1 people don't quite get it all yet. It is all fully optional and P2 can still look and operate quite a bit like a fast P1 when required.
Breakpoints!!! Yes! I didn't realize that this YIELD instruction would provide that part of the debugging puzzle.
The best thing is it doesn't need to be used if it seems foreign and some of the existing P1 people don't quite get it all yet. It is all fully optional and P2 can still look and operate quite a bit like a fast P1 when required.
YES!
This tasking discussion seems painful. There are a lot of details. However, what I have observed is we all contribute where we can. That gets factored down a few times into what are a few key functions.
If you want to ignore most of it, do! Maybe when it's all done, we can publish an instruction subset. Many P1 users will see that subset and know a whole lot about what is going on.
Breakpoints!!! Yes! I didn't realize that this YIELD instruction would provide that part of the debugging puzzle.
:-)
YIELD provides:
- a task or thread voluntarily shutting down
- a thread giving up the remainder of its timeslice
- many breakpoints
- a thread waiting for a signal, freeing the processing time for other threads
- system calls for standard I/O and more
By the way, after some more thinking... I'd prefer a full-two operand instruction
YIELD reg,#/S
as the upper bits could be used to specify a mask for any of 23 separate wakeup events when waiting
Don't worry - this isn't like some software nightmare. Hardware is much more straightforward and bugs are rarely subtle. I'm more concerned that we'll have the silicon area that we need and that the power consumption isn't too high.
Agreed. I have been doing both hardware and software (~50/50) for the past 40 years. Hardware is certainly the easiest to debug
Would it be better to make JMPTASK D/#,S/# provide a task number in D/# instead of a 4-bit mask?
The mask allows you to affect all tasks' PC's at once, but this is a very unusual circumstance, in practice, and complicates the instruction usage in most instances. If we just required a task number, instead of a 4-bit mask, it would make the instruction more intuitive for most use cases, but would not allow you to affect more than one PC at once. The only use case where you'd want to affect more than one PC at once with the same value might be an instance where you have remapped registers that will differentiate the tasks that are running the same program.
This came up because I'm adding the TPAUSE/TRESUME instructions and I was wondering if there would ever be a need to TRESUME more than one task at once. I think it will be easier to just use the task number.
This came up because I'm adding the TPAUSE/TRESUME instructions and I was wondering if there would ever be a need to TRESUME more than one task at once. I think it will be easier to just use the task number.
I can think of cases where TRESUME more than one task at once could be useful, - in areas like Multi-channel logging, users could have a trigger task, and then 3 capture tasks launch from that.
If the issue is only clarity / more intuitive for most use cases, then a simple pre DEFINE of Task numbers ( even in the Assembler) would allow clear normal use.
ie the #Task2 is one task, and #(Task1+Task2+Task3) does all 3 ?
Reset of all PC's is a 'blunt instrument' & less common, but a watchdog style checker might what to do that as a software reset ?
Would it be better to make JMPTASK D/#,S/# provide a task number in D/# instead of a 4-bit mask?
The mask allows you to affect all tasks' PC's at once, but this is a very unusual circumstance, in practice, and complicates the instruction usage in most instances. If we just required a task number, instead of a 4-bit mask, it would make the instruction more intuitive for most use cases, but would not allow you to affect more than one PC at once. The only use case where you'd want to affect more than one PC at once with the same value might be an instance where you have remapped registers that will differentiate the tasks that are running the same program.
This came up because I'm adding the TPAUSE/TRESUME instructions and I was wondering if there would ever be a need to TRESUME more than one task at once. I think it will be easier to just use the task number.
I can think of cases where TRESUME more than one task at once could be useful, - in areas like Multi-channel logging, users could have a trigger task, and then 3 capture tasks launch from that.
If the issue is only clarity / more intuitive for most use cases, then a simple pre DEFINE of Task numbers ( even in the Assembler) would allow clear normal use.
ie the #Task2 is one task, and #(Task1+Task2+Task3) does all 3 ?
Reset of all PC's is a 'blunt instrument' & less common, but a watchdog style checker might what to do that as a software reset ?
I changed it so that D/# provides a task number, instead of a mask, because I think it's going to simpler to deal with. Whenever I typed a JMPTASK instruction, I mentally downshifted into granny gear to be sure I was doing it right. That was always a bugaboo.
What you brought up, jmg, could be accomplished by an opposite type of approach. Suppose all tasks wound up in a "JZ somereg,@0" loop. All the 'scheduler' task would have to do is write a non-0 value to that register and everyone would be released.
I don't think you can TPAUSE/TRESUME more than one task at once
Chips question suggests you can, hence why I suggested using a DEFINED number, which allows all usages
- you can use a TaskNumber anytime you want, like this :
#Task2 is one task,
and
#(Task1+Task2+Task3) for the 3 others.
What you brought up, jmg, could be accomplished by an opposite type of approach. Suppose all tasks wound up in a "JZ somereg,@0" loop. All the 'scheduler' task would have to do is write a non-0 value to that register and everyone would be released.
How would you manage the case of Watchdog SW reset of all other threads ?
I changed it so that D/# provides a task number, instead of a mask, because I think it's going to simpler to deal with. Whenever I typed a JMPTASK instruction, I mentally downshifted into granny gear to be sure I was doing it right. That was always a bugaboo.
What you brought up, jmg, could be accomplished by an opposite type of approach. Suppose all tasks wound up in a "JZ somereg,@0" loop. All the 'scheduler' task would have to do is write a non-0 value to that register and everyone would be released.
One caveat about the TRESUME instruction (that increments a target task's PC to break it out of a TPAUSE), is that it can only be executed when the target task has nothing in the pipeline. If TRESUME were to be done to affect a task with instruction(s) in the pipeline, it would create an indeterminate mess.
One caveat about the TRESUME instruction (that increments a target task's PC to break it out of a TPAUSE), is that it can only be executed when the target task has nothing in the pipeline. If TRESUME were to be done to affect a task with instruction(s) in the pipeline, it would create an indeterminate mess.
Is that issue managed in HW, (to make it effectively invisible ), or is it an exposed risk needing special software rules ?
If so, what exactly are the consequences of a programmer error, and what is an indeterminate mess.
- so I will explain what *I* thought was happening based on the post I was replying to, so you can correct me
I thought:
1) INSTRUCTIONS FOR USE BY SCHEDULER, NORMALLY TASK#0 IN A COG
TPAUSE #n .... pause task N, write its state into the wide the scheduler can access TRESUME #n .... resume task N, restoring its state from the wide the scheduler could access (could be used to start a task from scratch)
and in the future, hopefully
TSTEP #n ... single steps one instruction of task N, using the WIDE so the scheduler/debugger can watch it
2) INSTRUCTION FOR USE BY THE TASK (OR THREAD RUNNING IN A TASK)
TBREAK dest,#code .... the breakpoint / yield / exit / system call I defined that you liked, ideally code is either immediate or supplied by S register
Please edit the above to show what you currently plan to implement so we are on the same page
Is that issue managed in HW, (to make it effectively invisible ), or is it an exposed risk needing special software rules ?
If so, what exactly are the consequences of a programmer error, and what is an indeterminate mess.
When a task has instructions in the pipeline, it's not in a settled state where its PC can just be incremented via TRESUME. The task receiving the TRESUME must be out of the pipeline. If its not, something really bad can happen, like an indeterminate mess.
So, when you see the result of a TPAUSE (where a task has written a value to a register and is then looping in place), you need to starve that task of any time slots and let it run out of the pipeline. Then, you can increment its PC with a TRESUME.
- so I will explain what *I* thought was happening based on the post I was replying to, so you can correct me
I thought:
1) INSTRUCTIONS FOR USE BY SCHEDULER, NORMALLY TASK#0 IN A COG
TPAUSE #n .... pause task N, write its state into the wide the scheduler can access TRESUME #n .... resume task N, restoring its state from the wide the scheduler could access (could be used to start a task from scratch)
and in the future, hopefully
TSTEP #n ... single steps one instruction of task N, using the WIDE so the scheduler/debugger can watch it
2) INSTRUCTION FOR USE BY THE TASK (OR THREAD RUNNING IN A TASK)
TBREAK dest,#code .... the breakpoint / yield / exit / system call I defined that you liked, ideally code is either immediate or supplied by S register
Please edit the above to show what you currently plan to implement so we are on the same page
Oh, yeah, we are all mixed up with the names, but I think we've got the concepts straight. Here are the four instructions that govern this thread business:
T3SAVE 'save state of task 3 into WIDEs
T3LOAD 'load state of task 3 from WIDEs
TPAUSE D,S/# 'write S/# to D and loop in place
TRESUME D/# 'increment PC of task D/#
T3SAVE, T3LOAD, and TRESUME must be executed when the target task is no longer executing (out of the pipeline and no time slots given to it).
TPAUSE is executed by a thread task to alert a scheduler task that it has reached a certain point and will eventually need a TRESUME to continue.
Single-stepping Task 3 can be done by giving it a single time slot, then taking it away, so that one instruction executes in task 3.
I saw the idea of YIELD floated in this discussion. I'm not advocating it be in the mix, or not be, just noting it's not in the summary. I'm unclear on what happened, and haven't re-read to catch up. So maybe ignore this observation.
Other than that, this whole messy discussion boiled down to something remarkably simple. Well done Chip.
IMHO, a user sufficiently advanced as to really make use of and or need this capability can understand the guidelines under which we know and will test it to work. Also IMHO, we really do need to identify a core set of tests and do them, so we can define "works as designed" so that "indeterminate mess" also makes sense. They will know what to look for and why when troubleshooting.
So, No. Nothing missing. The core things are there and accounted for. Going deeper is a clear case of diminishing returns. This adds a whole lot of software possibilities. I can't help but think how we worked the Smile out of P1 finding out it would do way more than most of us originally thought. It's gonna go this way with P2, and personally, I think that's one of the stronger arguments for stopping where we have in some cases. Defining too much in hardware can be just as limiting as failing to make sure the right doors are open in hardware can be. Until we put the tasks along with everything else to some more in-depth use, keeping it lean seems the right thing to do.
I saw the idea of YIELD floated in this discussion. I'm not advocating it be in the mix, or not be, just noting it's not in the summary.
Other than that, this whole messy discussion boiled down to something remarkably simple. Well done Chip.
TPAUSE is the same thing we were calling TYIELD before. It writes a value to some register and then loops to itself. The trouble with calling it TYIELD is that that name implies just one use case, which is kind of limiting. What it does is write a value like a MOV would and then loop to itself, pausing so to speak. What another task does upon noticing that value written to some register, is up to the programmer. It could be a 'yield', or a 'breakpoint', or anything else.
When a task has instructions in the pipeline, it's not in a settled state where its PC can just be incremented via TRESUME. The task receiving the TRESUME must be out of the pipeline. If its not, something really bad can happen, like an indeterminate mess.
That indeterminate mess sounds a little scary.
What are the upper and lower limits, of the minimum time-windows (measured in same thread cycles) that are imposed between two opcodes, to avoid this ?
If someone accidently edits their code to then violate that timing, what exact failure modes are there , or is that indeterminate (so they may not even notice it is now partly broken?)
So, when you see the result of a TPAUSE (where a task has written a value to a register and is then looping in place), you need to starve that task of any time slots and let it run out of the pipeline. Then, you can increment its PC with a TRESUME.
If someone fires a TRESUME on a task that is not starved, what happens ?
Because the INC occurs in a different time-slot, than the PC fetch, it would seem to be ok, from at least a strict PC value basis ?
If someone fires a TRESUME on a task that is not starved, what happens ?
Because the INC occurs in a different time-slot, than the PC fetch, it would seem to be ok, from at least a strict PC value basis ?
That indeterminate mess sounds a little scary.
What are the upper and lower limits, of the minimum time-windows (measured in same thread cycles) that are imposed between two opcodes, to avoid this ?
If someone accidently edits their code to then violate that timing, what exact failure modes are there , or is that indeterminate (so they may not even notice it is now partly broken?)
If someone fires a TRESUME on a task that is not starved, what happens ?
Because the INC occurs in a different time-slot, than the PC fetch, it would seem to be ok, from at least a strict PC value basis ?
I say 'indeterminate' because what happens would be a function of which pipeline stages have instructions in them belonging to the task getting the TRESUME (which is looping in a TPAUSE). That task's PC is getting incremented, already, as instructions enter the pipeline, and periodically reset to the TPAUSE address. Within the pipeline, there might be four different PC values floating around for that task. So, the task needs to be shut down before a TRESUME is done on it. If you didn't wait for the pipeline to clear and did that TRESUME, it might or might not take as expected. I guess that would be the outcome - it may just not work.
Once a scheduler task notices that TPAUSE is in effect, it would write a value to SETTASK that would starve the task looping in a TPAUSE. On the 4th or 5th instruction after SETTASK, it could do the TRESUME if it wanted to. When I write the documentation, I'll get it nailed down.
So, the failure mode, if the pipeline wasn't cleared, would be that it might not work, and the task would stay stuck in TPAUSE. I guess it's not that scary, after all.
Is it not possible that TPAUSE have internal Down-counter that counts pipeline counts.
And TRESUME can't restart before that counter is = 0.
I guess I could set a flag on TRESUME that would wait until the target task was out of the pipeline before incrementing its PC and clearing itself. I don't know if that would be a good idea, or not, though.
Comments
Don't worry - this isn't like some software nightmare. Hardware is much more straightforward and bugs are rarely subtle. I'm more concerned that we'll have the silicon area that we need and that the power consumption isn't too high.
Breakpoints!!! Yes! I didn't realize that this YIELD instruction would provide that part of the debugging puzzle.
YES!
This tasking discussion seems painful. There are a lot of details. However, what I have observed is we all contribute where we can. That gets factored down a few times into what are a few key functions.
If you want to ignore most of it, do! Maybe when it's all done, we can publish an instruction subset. Many P1 users will see that subset and know a whole lot about what is going on.
:-)
YIELD provides:
- a task or thread voluntarily shutting down
- a thread giving up the remainder of its timeslice
- many breakpoints
- a thread waiting for a signal, freeing the processing time for other threads
- system calls for standard I/O and more
By the way, after some more thinking... I'd prefer a full-two operand instruction
YIELD reg,#/S
as the upper bits could be used to specify a mask for any of 23 separate wakeup events when waiting
No need for NR, WC or WZ
Fingers crossed for the power consumption.
Would it be better to make JMPTASK D/#,S/# provide a task number in D/# instead of a 4-bit mask?
The mask allows you to affect all tasks' PC's at once, but this is a very unusual circumstance, in practice, and complicates the instruction usage in most instances. If we just required a task number, instead of a 4-bit mask, it would make the instruction more intuitive for most use cases, but would not allow you to affect more than one PC at once. The only use case where you'd want to affect more than one PC at once with the same value might be an instance where you have remapped registers that will differentiate the tasks that are running the same program.
This came up because I'm adding the TPAUSE/TRESUME instructions and I was wondering if there would ever be a need to TRESUME more than one task at once. I think it will be easier to just use the task number.
I can think of cases where TRESUME more than one task at once could be useful, - in areas like Multi-channel logging, users could have a trigger task, and then 3 capture tasks launch from that.
If the issue is only clarity / more intuitive for most use cases, then a simple pre DEFINE of Task numbers ( even in the Assembler) would allow clear normal use.
ie the #Task2 is one task, and #(Task1+Task2+Task3) does all 3 ?
Reset of all PC's is a 'blunt instrument' & less common, but a watchdog style checker might what to do that as a software reset ?
I don't think you can TPAUSE/TRESUME more than one task at once
I changed it so that D/# provides a task number, instead of a mask, because I think it's going to simpler to deal with. Whenever I typed a JMPTASK instruction, I mentally downshifted into granny gear to be sure I was doing it right. That was always a bugaboo.
What you brought up, jmg, could be accomplished by an opposite type of approach. Suppose all tasks wound up in a "JZ somereg,@0" loop. All the 'scheduler' task would have to do is write a non-0 value to that register and everyone would be released.
Chips question suggests you can, hence why I suggested using a DEFINED number, which allows all usages
- you can use a TaskNumber anytime you want, like this :
#Task2 is one task,
and
#(Task1+Task2+Task3) for the 3 others.
How would you manage the case of Watchdog SW reset of all other threads ?
Btw, I have an idea...
TBREAK dest,S/# ... for YIELD
Fits the TPAUSE/TRESUME convention, and it does provide breakpoints as one of its functions!
So, the two instructions would be TBREAK and TRESUME ?
I don't see any need for any other instructions, do you?
Is that issue managed in HW, (to make it effectively invisible ), or is it an exposed risk needing special software rules ?
If so, what exactly are the consequences of a programmer error, and what is an indeterminate mess.
Is that a new silicon opcode, or just as Assembler level alias mnemonic to make it clearer what you are doing ?
- so I will explain what *I* thought was happening based on the post I was replying to, so you can correct me
I thought:
1) INSTRUCTIONS FOR USE BY SCHEDULER, NORMALLY TASK#0 IN A COG
TPAUSE #n .... pause task N, write its state into the wide the scheduler can access
TRESUME #n .... resume task N, restoring its state from the wide the scheduler could access (could be used to start a task from scratch)
and in the future, hopefully
TSTEP #n ... single steps one instruction of task N, using the WIDE so the scheduler/debugger can watch it
2) INSTRUCTION FOR USE BY THE TASK (OR THREAD RUNNING IN A TASK)
TBREAK dest,#code .... the breakpoint / yield / exit / system call I defined that you liked, ideally code is either immediate or supplied by S register
Please edit the above to show what you currently plan to implement so we are on the same page
I introduced as YIELD in:
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1248284&viewfull=1#post1248284
Explained it a bit more in:
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG/page295
Chip liked it, as posted in:
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1248430&viewfull=1#post1248430
and in
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1248464&viewfull=1#post1248464
Chip really liked that it also handles breakpoints for debugging
I was getting lost in the FOG.
Brian
I think the task number is the way to go as well. I dislike the requirement for defines, etc...
When a task has instructions in the pipeline, it's not in a settled state where its PC can just be incremented via TRESUME. The task receiving the TRESUME must be out of the pipeline. If its not, something really bad can happen, like an indeterminate mess.
So, when you see the result of a TPAUSE (where a task has written a value to a register and is then looping in place), you need to starve that task of any time slots and let it run out of the pipeline. Then, you can increment its PC with a TRESUME.
Oh, yeah, we are all mixed up with the names, but I think we've got the concepts straight. Here are the four instructions that govern this thread business:
T3SAVE 'save state of task 3 into WIDEs
T3LOAD 'load state of task 3 from WIDEs
TPAUSE D,S/# 'write S/# to D and loop in place
TRESUME D/# 'increment PC of task D/#
T3SAVE, T3LOAD, and TRESUME must be executed when the target task is no longer executing (out of the pipeline and no time slots given to it).
TPAUSE is executed by a thread task to alert a scheduler task that it has reached a certain point and will eventually need a TRESUME to continue.
Single-stepping Task 3 can be done by giving it a single time slot, then taking it away, so that one instruction executes in task 3.
Are we missing anything?
Other than that, this whole messy discussion boiled down to something remarkably simple. Well done Chip.
IMHO, a user sufficiently advanced as to really make use of and or need this capability can understand the guidelines under which we know and will test it to work. Also IMHO, we really do need to identify a core set of tests and do them, so we can define "works as designed" so that "indeterminate mess" also makes sense. They will know what to look for and why when troubleshooting.
So, No. Nothing missing. The core things are there and accounted for. Going deeper is a clear case of diminishing returns. This adds a whole lot of software possibilities. I can't help but think how we worked the Smile out of P1 finding out it would do way more than most of us originally thought. It's gonna go this way with P2, and personally, I think that's one of the stronger arguments for stopping where we have in some cases. Defining too much in hardware can be just as limiting as failing to make sure the right doors are open in hardware can be. Until we put the tasks along with everything else to some more in-depth use, keeping it lean seems the right thing to do.
Good balance here.
TPAUSE is the same thing we were calling TYIELD before. It writes a value to some register and then loops to itself. The trouble with calling it TYIELD is that that name implies just one use case, which is kind of limiting. What it does is write a value like a MOV would and then loop to itself, pausing so to speak. What another task does upon noticing that value written to some register, is up to the programmer. It could be a 'yield', or a 'breakpoint', or anything else.
Yes, I agree with the limiting implication. Pause is more accurate and less defining.
That indeterminate mess sounds a little scary.
What are the upper and lower limits, of the minimum time-windows (measured in same thread cycles) that are imposed between two opcodes, to avoid this ?
If someone accidently edits their code to then violate that timing, what exact failure modes are there , or is that indeterminate (so they may not even notice it is now partly broken?)
If someone fires a TRESUME on a task that is not starved, what happens ?
Because the INC occurs in a different time-slot, than the PC fetch, it would seem to be ok, from at least a strict PC value basis ?
My question to this jmg's question.
Is it not possible that TPAUSE have internal Down-counter that counts pipeline counts.
And TRESUME can't restart before that counter is = 0.
I say 'indeterminate' because what happens would be a function of which pipeline stages have instructions in them belonging to the task getting the TRESUME (which is looping in a TPAUSE). That task's PC is getting incremented, already, as instructions enter the pipeline, and periodically reset to the TPAUSE address. Within the pipeline, there might be four different PC values floating around for that task. So, the task needs to be shut down before a TRESUME is done on it. If you didn't wait for the pipeline to clear and did that TRESUME, it might or might not take as expected. I guess that would be the outcome - it may just not work.
Once a scheduler task notices that TPAUSE is in effect, it would write a value to SETTASK that would starve the task looping in a TPAUSE. On the 4th or 5th instruction after SETTASK, it could do the TRESUME if it wanted to. When I write the documentation, I'll get it nailed down.
So, the failure mode, if the pipeline wasn't cleared, would be that it might not work, and the task would stay stuck in TPAUSE. I guess it's not that scary, after all.
I guess I could set a flag on TRESUME that would wait until the target task was out of the pipeline before incrementing its PC and clearing itself. I don't know if that would be a good idea, or not, though.