Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #18710 > unrolled thread
| Started by | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| First post | 2013-01-13 06:37 +0000 |
| Last post | 2013-01-13 12:44 +0000 |
| Articles | 20 on this page of 100 — 35 participants |
Back to article view | Back to comp.lang.forth
Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 06:37 +0000
Re: Parallax Propeller MK <mk@nospam.co.uk> - 2013-01-13 10:26 +0000
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:22 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-13 07:24 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 13:55 +0000
Re: Parallax Propeller mhx@iae.nl (Marcel Hendrix) - 2013-01-13 17:13 +0200
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 06:23 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:01 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 09:12 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:36 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 10:59 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 23:38 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-17 04:04 -0600
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-17 04:52 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:48 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:10 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:42 -0800
Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:05 -0500
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 08:41 -0600
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-05 10:21 -0800
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 21:37 +0100
Re: Parallax Propeller "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 10:44 -1000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 15:52 -0600
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:29 -0800
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:31 -0800
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:46 +0100
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-09 00:11 -0800
Re: Parallax Propeller anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-09 10:25 +0000
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 18:26 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:07 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:49 -0800
Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:04 -0500
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:21 -0800
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-16 18:09 -0500
Re: Parallax Propeller Ben Bradley <ben_u_bradley@etcmail.com> - 2013-01-18 21:07 -0500
Re: Parallax Propeller "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-01-19 10:06 +0000
Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-19 13:04 +0100
Re: Parallax Propeller "A. K." <akk@nospam.org> - 2013-01-19 13:22 +0100
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-19 13:38 +0100
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-19 17:12 +0100
Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-19 16:45 +0000
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 17:49 +0100
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 20:54 +0200
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 11:04 -0800
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 23:05 +0200
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-20 01:05 -0800
Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-20 12:11 +0100
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:53 +0200
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:26 +0200
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:23 -0600
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:18 -0600
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 20:32 +0100
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-20 18:08 -0600
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 17:12 -0500
Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-20 19:19 -0500
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 21:12 -0500
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-21 09:01 +0100
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-21 21:11 -0500
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-22 09:39 +0200
Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-22 10:14 -0500
Re: Parallax Propeller Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2013-01-20 02:03 +0000
Re: Parallax Propeller George Neuner <gneuner2@comcast.net> - 2013-01-19 12:29 -0500
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:29 -0500
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-24 14:03 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:55 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:03 -0800
Re: Parallax Propeller Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:02 +0100
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:13 -0800
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-29 09:15 +0100
Re: Parallax Propeller Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-01-30 12:19 +0000
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-30 21:18 +0100
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-30 22:57 -0800
Re: Parallax Propeller Alex McDonald <blog@rivadpm.com> - 2013-01-31 10:38 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:34 -0800
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 10:42 -0800
Re: Parallax Propeller bob@bob.com - 2013-01-19 19:56 -0600
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:40 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-24 23:26 +0000
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-25 11:49 -0500
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-25 09:25 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-25 21:57 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-26 18:07 -0500
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-27 00:50 -0800
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-27 03:30 -0600
Re: Parallax Propeller Dombo <dombo@disposable.invalid> - 2013-01-27 12:58 +0100
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:38 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-27 03:09 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:51 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-30 02:10 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-30 18:32 -0500
Re: Parallax Propeller David Schultz <abuse@127.0.0.1> - 2013-01-20 11:21 -0600
Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-13 16:24 +0000
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-14 10:51 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:06 +0000
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-16 13:43 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:27 +0000
Re: Parallax Propeller Rafael Deliano <rafael_deliano@arcor.de> - 2013-01-15 21:10 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:26 +0000
Re: Parallax Propeller gavino_himself <visploveslisp@gmail.com> - 2013-01-22 06:26 -0800
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:44 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-01-19 16:45 +0000 |
| Message-ID | <50facda1$0$599$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #18895 |
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 > > -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-01-20 17:49 +0100 |
| Message-ID | <HYidnQ_SJKOIvWHNnZ2dnUVZ8oWdnZ2d@lyse.net> |
| In reply to | #18897 |
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.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-01-19 20:54 +0200 |
| Message-ID | <vlqlf8hac0fc0gab9sooaf0teh8jqh2ajc@4ax.com> |
| In reply to | #18895 |
On Sat, 19 Jan 2013 17:12:50 +0100, David Brown <david.brown@removethis.hesbynett.no> wrote: > >> 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. With only 10-50 cores, you still would have to put multiple threads on each core. I wonder for you could make a pre-emptive kernel without interrupts ? You would end up into some ugly Win 3.x style co-operative kernel. At least you would need to have some kind of timer interrupt to handle runaway threads.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-01-19 11:04 -0800 |
| Message-ID | <7xy5fpf0zf.fsf@ruckus.brouhaha.com> |
| In reply to | #18900 |
upsidedown@downunder.com writes: > With only 10-50 cores, you still would have to put multiple threads on > each core. I wonder for you could make a pre-emptive kernel without > interrupts? I think we are talking about an embedded microcontroller connected to a few sensors and pushbuttons or something like that. Not a workstation or internet server. 8 tasks are probably plenty for many things.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-01-19 23:05 +0200 |
| Message-ID | <2p1mf899f685iob9g2ja08lpnq4bm3bq3f@4ax.com> |
| In reply to | #18901 |
On Sat, 19 Jan 2013 11:04:36 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >upsidedown@downunder.com writes: >> With only 10-50 cores, you still would have to put multiple threads on >> each core. I wonder for you could make a pre-emptive kernel without >> interrupts? > >I think we are talking about an embedded microcontroller connected to >a few sensors and pushbuttons or something like that. Not a workstation >or internet server. 8 tasks are probably plenty for many things. When considering that each external connection will need a dedicated task, there is not many tasks left for the actual application. Anyway, the I/O task needs to inform the main application that the I/O operation (such as reading a complete frame from the serial port) has ended. Of course, the main task could poll some shared memory location(s) and burning a lot of power doing that. Some low power "wait for interrupt" style instruction would help reduce the power consumption, in order to avoid the busy polling (especially if multiple signal sources needs to be polled). 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.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2013-01-20 01:05 -0800 |
| Message-ID | <b05dfb40-9486-4967-9a7b-e15b0074bcaf@p17g2000vbn.googlegroups.com> |
| In reply to | #18904 |
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. If there's no other work to do, and you put the main task to sleep, then it's possible that the overall software 'solution' didn't need to be parallel in the first place - time to re-think the design and simplify. Or, to put it another way, if the 'main-task' has to go to sleep while the serial task is running, then I would say the software has been designed "the wrong way around" - the *serial task* is the main task, and the programmer needs to rotate his perception of the problem he is trying to solve by 180 degrees! He has it backwards. Okay, enough pedantry from me!
[toc] | [prev] | [next] | [standalone]
| From | Arlet Ottens <usenet+5@c-scape.nl> |
|---|---|
| Date | 2013-01-20 12:11 +0100 |
| Message-ID | <50fbd0f3$0$6891$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #18918 |
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.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-01-20 13:53 +0200 |
| Message-ID | <lulnf8ldik9upqm676psleqodjsufcen39@4ax.com> |
| In reply to | #18923 |
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 :-).
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-01-20 13:26 +0200 |
| Message-ID | <aejnf8ph6dc417ugvm0a98i5d4rrbi9m4f@4ax.com> |
| In reply to | #18918 |
On Sun, 20 Jan 2013 01:05:27 -0800 (PST), Mark Wills <markrobertwills@yahoo.co.uk> 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. While this is true, quite a lot of protocols are essentially half-duplex request/response protocols (such as Modbus). While for instance TCP/IP is capable of full-duplex communication, many protocols built on TCP/IP are essentially half duplex request/response (such as http). Of course, the I/O core should be programmed to handle sending the request and assembling the response in true IBM mainframe I/O processor SNA style :-) >If there's no other work to do, and you put the main task to sleep, >then it's possible that the overall software 'solution' didn't need to >be parallel in the first place - time to re-think the design and >simplify. If the main task is doing something useful between issuing the request and before processing the result, then is the question, _how_ or _when_ the main task is going to process the I/O response without interrupts. Of course, the main task could poll the I/O status say every few hundred microseconds, this would force you to insert those polls all around your application code, making it hard to maintain. However, if the I/O-task (core) is polled at some slow application convenient rate (say 10 ms), the buffering requirements would be quite large. For a half duplex protocol, any latencies due to polling will kill the throughput due to the extra latencies (especially at high signaling rates). might be a solution in some cases, I have >Okay, enough pedantry from me! The original question was about how to use multiple cores (=tasks in traditional RTOS speak) without interrupts. While I understand the problem of implementing proper interrupt processing in current processors with long pipelines and large caches, I still think that at least some kind of "wait for interrupt" mechanism (i.e. flushing the pipeline, cache invalidation and going to low power sleep mode) and some mechanism to reactivate the code by an external pin or by writing a value to the power up register by some other core is needed. If you do not want to call this "interrupt", then it is an other story.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2013-01-19 14:23 -0600 |
| Message-ID | <kdev74$scj$1@dont-email.me> |
| In reply to | #18900 |
upsidedown@downunder.com wrote: > On Sat, 19 Jan 2013 17:12:50 +0100, David Brown > <david.brown@removethis.hesbynett.no> wrote: > >> >>> 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. > > With only 10-50 cores, you still would have to put multiple threads on > each core. I wonder for you could make a pre-emptive kernel without > interrupts ? Does it really need to be preemptive? > You would end up into some ugly Win 3.x style > co-operative kernel. There is nothing particularly wrong with cooperative multitasking, especially for embedded systems. > At least you would need to have some kind of > timer interrupt to handle runaway threads. > Or you could consider runaway threads to be defects. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2013-01-19 14:18 -0600 |
| Message-ID | <kdeuuv$qta$1@dont-email.me> |
| In reply to | #18895 |
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. > 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? > 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... >> 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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-01-20 20:32 +0100 |
| Message-ID | <J5CdnSFtEvLW22HNnZ2dnUVZ8rOdnZ2d@lyse.net> |
| In reply to | #18902 |
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. >> >
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2013-01-20 18:08 -0600 |
| Message-ID | <kdi0p6$9ta$1@dont-email.me> |
| In reply to | #18943 |
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
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2013-01-20 17:12 -0500 |
| Message-ID | <50FC6BC1.EFBD7190@bytecraft.com> |
| In reply to | #18895 |
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..
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2013-01-20 19:19 -0500 |
| Message-ID | <kdi1j2$i53$1@dont-email.me> |
| In reply to | #18945 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2013-01-20 21:12 -0500 |
| Message-ID | <50FCA421.2199B901@bytecraft.com> |
| In reply to | #18950 |
Mel Wilson wrote: > 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. :) w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-01-21 09:01 +0100 |
| Message-ID | <E8-dnVb1gpFQaGHNnZ2dnUVZ7oednZ2d@lyse.net> |
| In reply to | #18945 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2013-01-21 21:11 -0500 |
| Message-ID | <50FDF565.57943C37@bytecraft.com> |
| In reply to | #18954 |
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..
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-01-22 09:39 +0200 |
| Message-ID | <16gsf8p4v0rkap7tjb6gorudisve1bafpp@4ax.com> |
| In reply to | #18945 |
On Sun, 20 Jan 2013 17:12:17 -0500, Walter Banks <walter@bytecraft.com> 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. > >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. Of course you could design a core which restarts every time an external or internal interrupt occurs (such as a request packet sent by an other core), run to completion and pot core in low power halt state. Of course, this works for some problems, but sooner or later you end up with a hellish state machine, which remembers, where you were when the previous interrupt occurred.
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2013-01-22 10:14 -0500 |
| Message-ID | <kdmabu$olr$1@dont-email.me> |
| In reply to | #18986 |
upsidedown@downunder.com wrote: > Of course you could design a core which restarts every time an > external or internal interrupt occurs (such as a request packet sent > by an other core), run to completion and pot core in low power halt > state. > > Of course, this works for some problems, but sooner or later you end > up with a hellish state machine, which remembers, where you were when > the previous interrupt occurred. It does look as though the AVR TWI interface was designed to be controlled just that way. Mel.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web