Parallax Propeller

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.

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.

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

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

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.

On Sat, 19 Jan 2013 10:42:36 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>Ben Bradley <ben_u_bradley@etcmail.com> writes:
>> 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 GA144 has no interrupts since you just dedicate a processor to
>the event you want to listen for.  The processors have i/o ports
>(to external pins or to adjacent processors on the chip) that block
>on read, so the processor doesn't burn power while waiting for data.


I use timer interrupts mainly to have many nice accurate timers.

It makes it so easy.  I could use polled timers in main() but really
prefer the ease of an interrupt and if it doesn't require any context
switching, what could be easier ?

boB

In comp.arch.embedded Paul E. Bennett <Paul_E.Bennett@topmail.co.uk> wrote:
> 
> 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.
> 

Forget about I/O -- in modern systems I/O devices frequantly
are like a specialized processors.  Think about coordination
between different processors -- you need to get some info
from one processor to another ASAP and the info is nonatomic
so just writing it to shared RAM will not do.  And you
need intrrupt even in case of atomic info it the target
processor is doing something else at would not look at
the info otherwise.



-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

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!

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.

On Sun, 20 Jan 2013 01:05:27 -0800 (PST), Mark Wills
<markrobertwills@yahoo.co.uk> wrote:

>On Jan 19, 9:05&#4294967295;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.