RISC was always about supporting pipelining and it's subsequent superscalar. End of story.
The idea that less instruction types made for a faster processor was disproven very early on due to the resulting code bloat. For sure, there is many virtually unused instructions that have existed but there is also a vast number of newly coined instructions being added to various CPUs and DSPs and ASICs every year. Most will be thoughly pipelined designs.
But, it's a scheduled interruption, and not one of many that may compound at inopportune times.
Heh, that's far from the biggest issue people have with interrupts though. The processing is limited no matter what. Interrupts have always been handled one at a time, that's why level based shared IRQs work just fine.
I think, mostly, people just have trouble with the restricted/separate context and not knowing how to share data cleanly between those contexts.
But, it's a scheduled interruption, and not one of many that may compound at inopportune times.
It's not really scheduled from the point of view of the code that is being preempted. The preemption could happen at any time unpredictably from its point of view. In that sense, it's no different from an external hardware interrupt.
I know it was discussed but I don't know if it made it into the design. However, using YIELD isn't preemptive multi-tasking. It's cooperative multi-tasking. Preemption by definition means stopping another task in the middle of its execution at an unpredictable point. This is indistinguishable from a hardware interrupt to the task being preempted. You can, of course, used the task preemption mechnisim to implement interrupts in software. However, you'll get very high latency interrupts if you have to poll external events in software.
It can be used for both pre-emptive and cooperative multi-threading in task#3 of any cog. Note, task#0 has to be running (1/16 cycles is fine) to be able to service THALT, but does not necessarily have to pre-empt task#3 (thus THALT can be used for cooperative MT).
If you look at other processors, the MSP430 in this case, you see interrupts are at the very core of the architecture.
• Oscillator fault Note: Oscillator fault
The oscillator fault is maskable by an individual enable bit OFIE. It is not disabled during a general interrupt enable (GIE) reset.
The Propeller has no such functionality described in hardware.
That one is interesting, and seems to becoming more common in small micros, I think it is driven by Design standards like IEC 60730
Comments
The idea that less instruction types made for a faster processor was disproven very early on due to the resulting code bloat. For sure, there is many virtually unused instructions that have existed but there is also a vast number of newly coined instructions being added to various CPUs and DSPs and ASICs every year. Most will be thoughly pipelined designs.
Heh, that's far from the biggest issue people have with interrupts though. The processing is limited no matter what. Interrupts have always been handled one at a time, that's why level based shared IRQs work just fine.
I think, mostly, people just have trouble with the restricted/separate context and not knowing how to share data cleanly between those contexts.
It can be used for both pre-emptive and cooperative multi-threading in task#3 of any cog. Note, task#0 has to be running (1/16 cycles is fine) to be able to service THALT, but does not necessarily have to pre-empt task#3 (thus THALT can be used for cooperative MT).
That one is interesting, and seems to becoming more common in small micros, I think it is driven by Design standards like IEC 60730
http://am.renesas.com/applications/appliances/sub/iec60730-1_child.jsp
I wonder what the P2's IEC 60730 coverage is like ?