On Sun, 20 Jan 2013 12:11:46 +0100, Arlet Ottens <usenet+5@c-scape.nl> wrote:>On 01/20/2013 10:05 AM, Mark Wills wrote: >> On Jan 19, 9:05 pm, upsided...@downunder.com wrote: >>> Alternatively, the main task requesting a service (such as receiving a >>> frame) needs to send the request to the I/O task and then go to a low >>> power halt state. Upon completing the I/O task would have to power up >>> the halted task (hopefully from the same location it was halted and >>> not from the restart point :-). Things get ugly, if two or more >>> waiting tasks need to be informed. >> >> I don't 100% agree with that description! If you wrote your code like >> that then you end up with code written in a parallel style, but that >> executes in a serial (i.e. sequential) way! >> >> It's far better if the task that is waiting for a response from the >> serial I/O task goes off and does some other work while it is waiting. >> Otherwise what you have in reality is a sequential process written in >> a parallel style; in other words, it's far more complicated than it >> needs to be. > >Of course it would be preferable if the tasks could do other work, but >that requires an interrupt mechanism if you want to handle external >events with low and predictable latency.A system can be implemented in various ways. If the intertask synchronization and communication is very primitive (e.g. implemented in hardware only), you easily end up with dozens or even hundreds of very simple tasks doing a huge number of random communications with each other, making it hard to manage. On the other hand, if you are forced to a single task (old style Unix), you easily end up building some huge select() calls, including file descriptors from actual files, sockets and serial lines. This also makes it hard to maintain the system. There should be some sweet spot between these two extremes. A sufficiently usable intertask communication systems (typically using interrupts) should be able to handle this. I prefer 5-10 different tasks, so my fingers are sufficient to keep track of these, without having to take my socks off to use my toes for counting the rest :-).
Parallax Propeller
Started by ●January 13, 2013
Reply by ●January 20, 20132013-01-20
Reply by ●January 20, 20132013-01-20
On 19/01/13 17:45, Albert van der Horst wrote:> In article <tZidnZg9_bafW2fNnZ2dnUVZ8radnZ2d@lyse.net>, > David Brown <david.brown@removethis.hesbynett.no> wrote: >> >> Look how many interrupts a modern PC or large embedded system has - they >> outnumber the number of cores by 50 to 1 at least. Interrupts are not >> going away. > > A modern CPU has 10 cores. So you say that they have far more than > 500 interrupts. An Intel with an interrupt vector table of 500? > The largest IRQ I have seen fiddling in the BIOS startup screen is > 12. I may look at this the wrong way, but 500+ seems excessive. > > Groetjes Albert >> >>The BIOS only shows the IRQ lines available to the original PC, not those on the "extended" interrupt controller or multiplexed interrupt sources. A quick check on my PC shows 36 interrupts in use, with four cores. So my first guess was a bit of an exaggeration - though I don't know how many interrupt sources are available. But it is also not hard to find large microcontrollers with hundreds of interrupt sources and only 1 or two cores, giving much more than 50 to 1 ratio. Of course, any given system is unlikely to use more than a small fraction of the interrupt sources - but even something as simple as a UART can use three interrupts plus some sort of timer. But it will still be a lot more than the number of cores.
Reply by ●January 20, 20132013-01-20
On 01/18/2013 08:07 PM, Ben Bradley wrote:> It's against that designer guru guy's religion or something.I remember reading an article in Nuts & Volts on the propeller which discussed the interrupt thing. Digging into the archives... "There were only a few rules: it had to be fast, it had to be relatively easy to program, and it had to be able to do multiple tasks without using interrupts -- the bane of all but the heartiest programmers." April 2006, page 16. In other words, interrupts are too hard. By this standard, I am a hearty programmer. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving
Reply by ●January 20, 20132013-01-20
On Saturday, January 19, 2013 5:06:24 AM UTC-5, Paul E. Bennett wrote:> ... I suspect the need for interrupts will wane.And FORTH will rise again ! Sorry, couldn't help myself... PS: Yes, I have programmed complicated IO processing on a minicomputer without interrupts. And my next task was adding an interrupt controller ;-)
Reply by ●January 20, 20132013-01-20
On 19/01/13 21:18, Les Cargill wrote:> David Brown wrote: >> (Please do not snip newsgroups by using "followup to", unless the post >> really is off-topic in a group.) >> >> >> On 19/01/13 11:06, Paul E. Bennett wrote: >>> Ben Bradley wrote: >>> >>>> U=In comp.lang.forth,comp.arch.embedded On Sun, 13 Jan 2013 13:55:22 >>>> GMT, Peter Jakacki <peterjakacki@gmail.com> wrote: >>> >>> [%X] >>> >>>>> The P2 which is due to be released soon >>>> >>>> ... still has zero interrupts. >>>> >>>> Yes, I first saw the propellor mentioned years ago, the 8 32-bit cores >>>> thing sounds nice, but no interrupts was a deal killer for me. A year >>>> or two back (with maybe earlier mention of the P2) I looked on the >>>> "official" support/discussion forums for the Propellor and saw this >>>> longish thread on "why doesn't it have interrupts" and there were >>>> posts there that covered every objection I've had or seen to a >>>> microcontroller not having interrupts, even "why not add interrupts? >>>> It would take very little silicon and you don't have to use 'em if you >>>> don't want to." It's against that designer guru guy's religion or >>>> something. >>>> >>>> As far as I know there's no other microcontroller that doesn't have >>>> interrupts, and I can't recall one that didn't. The Apple ][ didn't >>>> use interrupts even though the 6502 had them. Maybe there were some >>>> 4-bit microprocessors that didn't have any interrupts. >> >> Were there not small Microchip PIC devices without interrupts? The >> PIC12 series, or something like that (I didn't use them myself). >> >>> >>> One question you should ask yourself is why you think a parallel >>> processor >>> (particularly the mesh organised ones) really need to include >>> interrupts. >>> You have many processors, all the same, simple, no frills. You can >>> afford to >>> dedicate a processor to deal with inputs that need to be responded to >>> rapidly without the need for interrupts. I know that, to some, it >>> might seem >>> a waste of a processor, but with heavily parallel chips you could >>> afford to >>> think about how you allocate I/O around the processor array. >>> >> >> That argument might have merit /if/ this chip had many processors. It >> only has 8. I think the idea of splitting a design into multiple >> simple, semi-independent tasks that all work on their own >> cpu/core/thread, in their own little worlds, is very elegant. It can >> give great modularisation, re-use of software-components, and easy >> testing. But you need /many/ more than 8 threads for such a system with >> real-world programs - otherwise you have to combine tasks within the >> same thread, and you have lost all the elegance. >> > > You can still design them as if they were in their own thread and > run them in "series". The now-old CASE tool ObjecTime had a separate > set of screen widgets for organizing separate "executables" into > threads. > > In non-case-tool systems, you simply run them one after the other. > This can be round-robin or through a more sophisticated arrangement. >You can certainly do that - but then you don't get the dedication of a core that lets you get low-latency reactions.>> So then you might have a system with lots more cores - say 64 cores. >> Then you have enough to do quite a number of tasks. But to get that >> with a realistic price, power and size, these cores will be very simple >> and slow - which means that you can't do tasks that require a single >> core running quickly. >> >> What makes a lot more sense is to have a cpu that has hardware support >> for a RTOS, and is able to switch rapidly between different tasks. > > An RTOS can also be a purely software object. Do mean essentially > register bank switching?Bank switching is part of it, but to make a "hardware RTOS" you need a system to switch tasks (register banks) automatically by task.> >> That >> way demanding tasks can get the cpu time they need, while you can also >> have lots of very simple tasks that give you the modularisation in code >> without having to dedicate lots of silicon. The XMOS does a bit of >> this, in that it has 8 threads per cpu that can run up to 100 MIPS each >> (IIRC), but with a total of 500 MIPS per cpu, and it also has >> inter-process communication in hardware. >> >> > > Shared memory has been around since System V, so...There is a lot more to inter-process communication than shared memory. The XMOS implements a message passing system with CSP-style synchronisation.> >>> Check back in the history of processors and you will see why the >>> interrupt >>> was thought to be necessary in the first place. With the world >>> heading to >>> the much more use of multi-parallel processor I suspect the need for >>> interrupts will wane. >>> >> >> Look how many interrupts a modern PC or large embedded system has - they >> outnumber the number of cores by 50 to 1 at least. Interrupts are not >> going away. >> >
Reply by ●January 20, 20132013-01-20
David Brown wrote:> (Please do not snip newsgroups by using "followup to", unless the post > really is off-topic in a group.) > > On 19/01/13 11:06, Paul E. Bennett wrote: > > Ben Bradley wrote: > > > >> U=In comp.lang.forth,comp.arch.embedded On Sun, 13 Jan 2013 13:55:22 > >> GMT, Peter Jakacki <peterjakacki@gmail.com> wrote: > > > > [%X] > > > >>> The P2 which is due to be released soon > >> > >> ... still has zero interrupts. > >> > >> Yes, I first saw the propellor mentioned years ago, the 8 32-bit cores > >> thing sounds nice, but no interrupts was a deal killer for me. A year > >> or two back (with maybe earlier mention of the P2) I looked on the > >> "official" support/discussion forums for the Propellor and saw this > >> longish thread on "why doesn't it have interrupts" and there were > >> posts there that covered every objection I've had or seen to a > >> microcontroller not having interrupts, even "why not add interrupts? > >> It would take very little silicon and you don't have to use 'em if you > >> don't want to." It's against that designer guru guy's religion or > >> something. > >> > >> As far as I know there's no other microcontroller that doesn't have > >> interrupts, and I can't recall one that didn't. The Apple ][ didn't > >> use interrupts even though the 6502 had them. Maybe there were some > >> 4-bit microprocessors that didn't have any interrupts. > > Were there not small Microchip PIC devices without interrupts? The > PIC12 series, or something like that (I didn't use them myself). > > > > > One question you should ask yourself is why you think a parallel processor > > (particularly the mesh organised ones) really need to include interrupts. > > You have many processors, all the same, simple, no frills. You can afford to > > dedicate a processor to deal with inputs that need to be responded to > > rapidly without the need for interrupts. I know that, to some, it might seem > > a waste of a processor, but with heavily parallel chips you could afford to > > think about how you allocate I/O around the processor array. > > > > That argument might have merit /if/ this chip had many processors. It > only has 8. I think the idea of splitting a design into multiple > simple, semi-independent tasks that all work on their own > cpu/core/thread, in their own little worlds, is very elegant. It can > give great modularisation, re-use of software-components, and easy > testing. But you need /many/ more than 8 threads for such a system with > real-world programs - otherwise you have to combine tasks within the > same thread, and you have lost all the elegance. > > So then you might have a system with lots more cores - say 64 cores. > Then you have enough to do quite a number of tasks. But to get that > with a realistic price, power and size, these cores will be very simple > and slow - which means that you can't do tasks that require a single > core running quickly. > > What makes a lot more sense is to have a cpu that has hardware support > for a RTOS, and is able to switch rapidly between different tasks. That > way demanding tasks can get the cpu time they need, while you can also > have lots of very simple tasks that give you the modularisation in code > without having to dedicate lots of silicon. The XMOS does a bit of > this, in that it has 8 threads per cpu that can run up to 100 MIPS each > (IIRC), but with a total of 500 MIPS per cpu, and it also has > inter-process communication in hardware. > > > Check back in the history of processors and you will see why the interrupt > > was thought to be necessary in the first place. With the world heading to > > the much more use of multi-parallel processor I suspect the need for > > interrupts will wane. > > > > Look how many interrupts a modern PC or large embedded system has - they > outnumber the number of cores by 50 to 1 at least. Interrupts are not > going away.Interrupts are not going away anytime soon. There are event riven processors that are essentially all interrupts. Add run to completion (to eliminate preemption overhead) and multiple cores for interrupts to use the next available execution unit and a lot of processing overheads go away with comparable reduction in software complexity. w..
Reply by ●January 20, 20132013-01-20
David Brown wrote:> On 19/01/13 21:18, Les Cargill wrote: >> David Brown wrote: >>> (Please do not snip newsgroups by using "followup to", unless the post >>> really is off-topic in a group.) >>> >>> >>> On 19/01/13 11:06, Paul E. Bennett wrote: >>>> Ben Bradley wrote: >>>> >>>>> U=In comp.lang.forth,comp.arch.embedded On Sun, 13 Jan 2013 13:55:22 >>>>> GMT, Peter Jakacki <peterjakacki@gmail.com> wrote: >>>> >>>> [%X] >>>> >>>>>> The P2 which is due to be released soon >>>>> >>>>> ... still has zero interrupts. >>>>> >>>>> Yes, I first saw the propellor mentioned years ago, the 8 32-bit cores >>>>> thing sounds nice, but no interrupts was a deal killer for me. A year >>>>> or two back (with maybe earlier mention of the P2) I looked on the >>>>> "official" support/discussion forums for the Propellor and saw this >>>>> longish thread on "why doesn't it have interrupts" and there were >>>>> posts there that covered every objection I've had or seen to a >>>>> microcontroller not having interrupts, even "why not add interrupts? >>>>> It would take very little silicon and you don't have to use 'em if you >>>>> don't want to." It's against that designer guru guy's religion or >>>>> something. >>>>> >>>>> As far as I know there's no other microcontroller that doesn't have >>>>> interrupts, and I can't recall one that didn't. The Apple ][ didn't >>>>> use interrupts even though the 6502 had them. Maybe there were some >>>>> 4-bit microprocessors that didn't have any interrupts. >>> >>> Were there not small Microchip PIC devices without interrupts? The >>> PIC12 series, or something like that (I didn't use them myself). >>> >>>> >>>> One question you should ask yourself is why you think a parallel >>>> processor >>>> (particularly the mesh organised ones) really need to include >>>> interrupts. >>>> You have many processors, all the same, simple, no frills. You can >>>> afford to >>>> dedicate a processor to deal with inputs that need to be responded to >>>> rapidly without the need for interrupts. I know that, to some, it >>>> might seem >>>> a waste of a processor, but with heavily parallel chips you could >>>> afford to >>>> think about how you allocate I/O around the processor array. >>>> >>> >>> That argument might have merit /if/ this chip had many processors. It >>> only has 8. I think the idea of splitting a design into multiple >>> simple, semi-independent tasks that all work on their own >>> cpu/core/thread, in their own little worlds, is very elegant. It can >>> give great modularisation, re-use of software-components, and easy >>> testing. But you need /many/ more than 8 threads for such a system with >>> real-world programs - otherwise you have to combine tasks within the >>> same thread, and you have lost all the elegance. >>> >> >> You can still design them as if they were in their own thread and >> run them in "series". The now-old CASE tool ObjecTime had a separate >> set of screen widgets for organizing separate "executables" into >> threads. >> >> In non-case-tool systems, you simply run them one after the other. >> This can be round-robin or through a more sophisticated arrangement. >> > > You can certainly do that - but then you don't get the dedication of a > core that lets you get low-latency reactions. >To be sure.>>> So then you might have a system with lots more cores - say 64 cores. >>> Then you have enough to do quite a number of tasks. But to get that >>> with a realistic price, power and size, these cores will be very simple >>> and slow - which means that you can't do tasks that require a single >>> core running quickly. >>> >>> What makes a lot more sense is to have a cpu that has hardware support >>> for a RTOS, and is able to switch rapidly between different tasks. >> >> An RTOS can also be a purely software object. Do mean essentially >> register bank switching? > > Bank switching is part of it, but to make a "hardware RTOS" you need a > system to switch tasks (register banks) automatically by task. >I presume the code store is shared, so it's matter of assigning the "task" represented by entry point <x> to core <y>.>> >>> That >>> way demanding tasks can get the cpu time they need, while you can also >>> have lots of very simple tasks that give you the modularisation in code >>> without having to dedicate lots of silicon. The XMOS does a bit of >>> this, in that it has 8 threads per cpu that can run up to 100 MIPS each >>> (IIRC), but with a total of 500 MIPS per cpu, and it also has >>> inter-process communication in hardware. >>> >>> >> >> Shared memory has been around since System V, so... > > There is a lot more to inter-process communication than shared memory. > The XMOS implements a message passing system with CSP-style > synchronisation. >Very nice indeed, then. CSP is the right abstraction.>> >>>> Check back in the history of processors and you will see why the >>>> interrupt >>>> was thought to be necessary in the first place. With the world >>>> heading to >>>> the much more use of multi-parallel processor I suspect the need for >>>> interrupts will wane. >>>> >>> >>> Look how many interrupts a modern PC or large embedded system has - they >>> outnumber the number of cores by 50 to 1 at least. Interrupts are not >>> going away. >>> >> >-- Les Cargill
Reply by ●January 20, 20132013-01-20
Walter Banks wrote:> There are event riven processors that are essentially all interrupts.There are no spelling mistakes. Only unexpected meanings. Not even unexpected, sometimes. Mel.
Reply by ●January 21, 20132013-01-21
On 20/01/13 23:12, Walter Banks wrote:> Interrupts are not going away anytime soon. > > There are event riven processors that are essentially all interrupts.I have often written programs where the main loop contains nothing but a "sleep until next interrupt" instruction - it is not uncommon for low-power systems.> > Add run to completion (to eliminate preemption overhead) and multiple > cores for interrupts to use the next available execution unit and a lot of > processing overheads go away with comparable reduction in software > complexity. >If you can eliminate all forms of pre-emption, you can keep many things simpler - there is no need to worry about how you share data or resources amongst threads, for example. But of course you can no longer have low-latency reactions to events - you need to make sure these are handled in hardware.
Reply by ●January 21, 20132013-01-21
David Brown wrote:> On 20/01/13 23:12, Walter Banks wrote: > > Interrupts are not going away anytime soon. > > > > There are event riven processors that are essentially all interrupts. > > I have often written programs where the main loop contains nothing but a > "sleep until next interrupt" instruction - it is not uncommon for > low-power systems. > > > > > Add run to completion (to eliminate preemption overhead) and multiple > > cores for interrupts to use the next available execution unit and a lot of > > processing overheads go away with comparable reduction in software > > complexity. > > > > If you can eliminate all forms of pre-emption, you can keep many things > simpler - there is no need to worry about how you share data or > resources amongst threads, for example. But of course you can no longer > have low-latency reactions to events - you need to make sure these are > handled in hardware.Latency in these systems is reduced in two ways, pre computing responses delivered on an event (your comment) and multiple execution units so code is not pre-empted but is immediately executed if there is an available execution unit. Hardware arbitrated execution priority levels is also a feature of these processors The rest is software design to make sure the response time meets the application requirements. The resulting code has better average response time and that can be important as well. w..
