Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> On 15.7.17 00:45, Dimiter_Popoff wrote:
> 
>> I can't think of a single non-68k/coldfire processor which has the
>> multiple priority interrupt levels (but I don't know ARM) or an
>> equivalent. Did ARM come that much of age? I'd be surprised.
> Cortex does. In the architecture there are 255 levels which
> can be broken at a bit boundary to main levels and sublevels,
> e.g. 32 main levels with 8 sublevels each (depending on the
> chip implementor's decision).

These days, almost all processors have interrupt proprity levels. 
However none that I know of handle them as elegantly as Cortex-M, and 
instead require some combination of manual context saving and interrupt 
masking.

-a

On 07/15/17 01:04, Dimiter_Popoff wrote:
> On 15.7.2017 &#1075;. 02:00, Chris wrote:
>> On 07/14/17 21:45, Dimiter_Popoff wrote:
>>
>>>
>>> I can't think of a single non-68k/coldfire processor which has the
>>> multiple priority interrupt levels (but I don't know ARM) or an
>>> equivalent. Did ARM come that much of age? I'd be surprised.

The basic 68k did interrupt priorities in hardware, fwir. 3 bits of
input to the chip, usually driven by a ttl 8-3 line priority
encoder, with hardwired inputs to set priority. Not sure about the
-020 and later details, but fwir, all later versions has a relocatable
vector table at least, whereas in the original, it was fixed.

I worked on a project using the Dragonball VZ and that was far more
interesting, with relocatable vector table, control register, mask
register, status register, pending register and level (priority)
register, all interrupt related. Only used a fraction of the
capability, but good to have it there.

Last project used a Renesas device, which looked like the old Hitachi
8 bit series + 8 added address bits. Far from being a clean
architecture but got the job done.

As for ARM, only have limited experience of Cortex M3 and still
haven't worked a project using it, which is where you really find
out how good it is. On paper though, it ticks all the boxes
from every angle, eg; has borrowed all the Dragonball int ideas and
then some. The best book on the M3 is probably the Joseph Yiu
Definitive Guide to the Arm Cortex M3. Expensive and goes on a bit
in places, but more concise than the official docs.

Has Arm come of age ?, yes, I think so and worth digging into...

Chris

On 15/07/17 10:53, Tauno Voipio wrote:
> On 15.7.17 00:45, Dimiter_Popoff wrote:
> 
>> I can't think of a single non-68k/coldfire processor which has the
>> multiple priority interrupt levels (but I don't know ARM) or an
>> equivalent. Did ARM come that much of age? I'd be surprised.
> 
> Cortex does. 

Cortex M, anyway.  I don't know about Cortex R and Cortex A cores.  I'd 
guess Cortex R also have nested priority interrupt support, but perhaps 
Cortex A is simpler (since this is a feature you want for real-time 
control, not for application processors).

> In the architecture there are 255 levels which
> can be broken at a bit boundary to main levels and sublevels,
> e.g. 32 main levels with 8 sublevels each (depending on the
> chip implementor's decision).

Yes.  Interrupts at higher main priority levels can break in while you 
are executing a lower level interrupt.  Sublevels are used to determine 
which interrupt on the same main level is handled first when there are 
multiple interrupts triggered.

> 
> There is an exception (internally triggered interrupt) for
> thread switching (PENDSV), and it simplifies the core thread
> switching when run on lowest priority.
> 
> The Cortex interrupt mechanism can handle nested interrupts
> with plain C functions, and the nesting mechanism is up and
> running in normal case. An interrupt handler has to disable
> higher-priority interrupts if it wants to be alone.
> 

The Cortex M also has "interrupt chaining".  When an interrupt is 
triggered, it pushes some of the key registers onto the stack before 
calling the interrupt function.  If a new interrupt (at the same or 
lower level) is triggered before the first returns, then the processor 
skips the restore and re-stack of these registers before moving on to 
the new interrupt function.

On 15.7.17 00:45, Dimiter_Popoff wrote:

> I can't think of a single non-68k/coldfire processor which has the
> multiple priority interrupt levels (but I don't know ARM) or an
> equivalent. Did ARM come that much of age? I'd be surprised.

Cortex does. In the architecture there are 255 levels which
can be broken at a bit boundary to main levels and sublevels,
e.g. 32 main levels with 8 sublevels each (depending on the
chip implementor's decision).

There is an exception (internally triggered interrupt) for
thread switching (PENDSV), and it simplifies the core thread
switching when run on lowest priority.

The Cortex interrupt mechanism can handle nested interrupts
with plain C functions, and the nesting mechanism is up and
running in normal case. An interrupt handler has to disable
higher-priority interrupts if it wants to be alone.

-- 

-TV

On 15.7.2017 &#1075;. 02:00, Chris wrote:
> On 07/14/17 21:45, Dimiter_Popoff wrote:
>
>>
>> I can't think of a single non-68k/coldfire processor which has the
>> multiple priority interrupt levels (but I don't know ARM) or an
>> equivalent. Did ARM come that much of age? I'd be surprised.
>
> Neither do I. At the time, we avidly followed developments in Byte
> magazine and remember being so impressed by the 68K architecture,
> went out and spent a fortune on the 68KECB, just to learn about it.
> It's the architecture that all others since have been compared
> against, often unfavorably, but Motorola were influenced by
> older mini architectures such as pdp11, or even Vax. "Get as much
> mini arch into a micro as possible", I think was the reasoning. I
> bet it would still be competitive even now with modern process
> technology, but of course, CISC is out of fashion these days.

Well the prioritized scheme needs not be on CISC, e.g. on power a
pair of registers to save the PC and the MSR per priority level
would suffice (this is how they did the FIRQ). Of course and a
RTI (rfi on power) opcode, different per level - and working :-).

>
>>
>> Even power do not have it, some cores do have a FIRQ which has
>> priority over IRQ (i.e. will interrupt an IRQ handler). On the core
>> I use (and did not use the FIRQ) there is a hardware mess with the
>> return from FIRQ opcodes - and IIRC the suggested workaround would
>> kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was
>> to copy the FIRQ return registers to those for IRQ and exectute
>> a return from IRQ.... too bad if you had just interrupted an IRQ
>> handler).
>>
>
> Older arm arch was a mess, imho, looking like bits had been glued
> on all over the place. The idea of IRQ and FIRQ harks back to 6800
> and 6502's IRQ and NMI, which served similar functions.

NMI was too cruel, I used it for step by step tracing only. They
introduced the FIRQ on the 6809 (they being Motorola, obviously);
perhaps were forced to as IRQ pushed all the registers and the 09 had
a lot more than the 6800 (which pushed all IIRC in about 20uS @1 MHz...)
The FIRQ on the 09 pushed just the CCR and the PC, 3 bytes.

> If they could
> build compiler friendly orthoganal architecture micros 30 years ago,
> there's no excuse not to do it now...

The guy who made power must have been really good, apart from the
missing interrupt levels I can't say I have many wishes. In fact I
live fine as it is, I just think of the moment I might need them :D.
This has been some 30 years ago... still the architecture the rest want
to catch up with.

Then on the mpc5200B (the one in heaviest use here) there is an
interrupt peripheral, which prioritizes the interrupts 68k style
and feeds them via the single IRQ line to the core. I have not
needed to do it but with a few reads and writes at the beginning of
the IRQ handler and perhaps at its end one could emulate the complete
68k thing I believe (never seriously looked into it though, would
take unmasking the irq in the core after stacking some stuff and
making the intrerrupt controller shut up for the current and lower
priorities).

  ======================================================
  Dimiter Popoff, TGI             http://www.tgi-sci.com
  ======================================================
  http://www.flickr.com/photos/didi_tgi/

On 7/14/17 5:45 PM, Dimiter_Popoff wrote:
> On 12.7.2017 &#1075;. 02:16, Chris wrote:
>> ...
>> I guess you are talking arm?. FIRQ is a leftover from early arm, fwir.
>> Have you seen amount of tortuous code needed to get interrupts
>> working properly with Arm7TDMI, for example?. About 2 pages of dense
>> assembler, from memory. I rejected early arm almost on that basis
>> alone, but there were other idiosyncracies. They fixed it eventually
>> with a proper (68K) style vector table, but it took them a long time
>> :-). Cortex was when Arm finally came of age.
> 
> I can't think of a single non-68k/coldfire processor which has the
> multiple priority interrupt levels (but I don't know ARM) or an
> equivalent. Did ARM come that much of age? I'd be surprised.
> 
> Even power do not have it, some cores do have a FIRQ which has
> priority over IRQ (i.e. will interrupt an IRQ handler). On the core
> I use (and did not use the FIRQ) there is a hardware mess with the
> return from FIRQ opcodes - and IIRC the suggested workaround would
> kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was
> to copy the FIRQ return registers to those for IRQ and exectute
> a return from IRQ.... too bad if you had just interrupted an IRQ
> handler).
> 
> Dimiter
>

The Microchip Pic24/dsPIC processors have a real priority interrupt 
system, where interrupts can automatically interrupt lower priority isrs.

Its been a while since I dug into the Arm architecture at that level, 
but from what I remember, one irq handler naturally blocks all irq 
handlers, but if the handler saves a few things to the irq stack (like 
the link register which holds where to return to), it can re-enable the 
irq interrupt to allow nested interrupts.

On 07/14/17 21:45, Dimiter_Popoff wrote:

>
> I can't think of a single non-68k/coldfire processor which has the
> multiple priority interrupt levels (but I don't know ARM) or an
> equivalent. Did ARM come that much of age? I'd be surprised.

Neither do I. At the time, we avidly followed developments in Byte
magazine and remember being so impressed by the 68K architecture,
went out and spent a fortune on the 68KECB, just to learn about it.
It's the architecture that all others since have been compared
against, often unfavorably, but Motorola were influenced by
older mini architectures such as pdp11, or even Vax. "Get as much
mini arch into a micro as possible", I think was the reasoning. I
bet it would still be competitive even now with modern process
technology, but of course, CISC is out of fashion these days.

>
> Even power do not have it, some cores do have a FIRQ which has
> priority over IRQ (i.e. will interrupt an IRQ handler). On the core
> I use (and did not use the FIRQ) there is a hardware mess with the
> return from FIRQ opcodes - and IIRC the suggested workaround would
> kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was
> to copy the FIRQ return registers to those for IRQ and exectute
> a return from IRQ.... too bad if you had just interrupted an IRQ
> handler).
>

Older arm arch was a mess, imho, looking like bits had been glued
on all over the place. The idea of IRQ and FIRQ harks back to 6800
and 6502's IRQ and NMI, which served similar functions. If they could
build compiler friendly orthoganal architecture micros 30 years ago,
there's no excuse not to do it now...

Chris

On 12.7.2017 &#1075;. 02:16, Chris wrote:
> ...
> I guess you are talking arm?. FIRQ is a leftover from early arm, fwir.
> Have you seen amount of tortuous code needed to get interrupts
> working properly with Arm7TDMI, for example?. About 2 pages of dense
> assembler, from memory. I rejected early arm almost on that basis
> alone, but there were other idiosyncracies. They fixed it eventually
> with a proper (68K) style vector table, but it took them a long time
> :-). Cortex was when Arm finally came of age.

I can't think of a single non-68k/coldfire processor which has the
multiple priority interrupt levels (but I don't know ARM) or an
equivalent. Did ARM come that much of age? I'd be surprised.

Even power do not have it, some cores do have a FIRQ which has
priority over IRQ (i.e. will interrupt an IRQ handler). On the core
I use (and did not use the FIRQ) there is a hardware mess with the
return from FIRQ opcodes - and IIRC the suggested workaround would
kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was
to copy the FIRQ return registers to those for IRQ and exectute
a return from IRQ.... too bad if you had just interrupted an IRQ
handler).

Dimiter

  ======================================================
  Dimiter Popoff, TGI             http://www.tgi-sci.com
  ======================================================
  http://www.flickr.com/photos/didi_tgi/

On 07/14/17 18:20, David Brown wrote:

> Yes, it does.
>
> It is not a /huge/ advance - it is not that hard to use
> "__attribute__((interrupt))" or a #pragma on your interrupt functions.
> But it is nice and convenient, and more efficient than compiler
> instructions to stack the volatile registers.
>
> Indeed, its convenience has a negative effect - you need to be careful
> to name your interrupt functions appropriately, because it is not
> obvious that they /are/ interrupt functions!

I have a naming convention to handle that, if that's what you are
getting at.

timer_drvr.c    upper level timer driver code
timer_isr.c     lower level interrupt handler

Same for anything else interrupt related..

Chris