PowerPC exceptions and interrupts

[Till Straumann]

Sebastian Huber wrote:
> Hi,
> I adapted the shared exception and interrupt 
> (libcpu/powerpc/new-exceptions/*) code to work with the e200z6 and this 
> lead to some comments.
>
> The current code implicitly defines BSP_SHARED_HANDLER_SUPPORT. I 
> modified it to support this preprocessor directive. Where is the right 
> place to define it?
>   
IMHO this symbol should go away altogether. Implementing
shared interrupts (more than 1 handler per IRQ) should be
mandatory. It doesn't consume a lot of resources; especially
if not used (the 'install' routine could be split into a separate
file so that it is not linked if unused).

The current situation is ugly -- if you don't include the file
where BSP_SHARED_HANDLER_SUPPORT is defined prior to
including rtems/irq.h then you don't get the correct declarations
IIRC.
> Currently the shared interrupt handler support works like a stack. You 
> can push and pop a handler. But in BSP_remove_rtems_irq_handler is also 
> code that removes the handler from a list. What was intended?
>   
? I guess I don't understand this point. I don't know of any
routines (we're talking about new-execeptions/bspsupport/irq.c, right?)
to push/pop interrupts. BSP_install_rtems_shared_irq_handler
adds a handler at the head of the list of handlers,
BSP_remove_rtems_irq_handler extracts a handler from the list.

> The interrupt support code only ensures that interrupts are disabled 
> during critical sections. May it be useful to add a mutex to support 
> usage in multiple threads?
>   
No. Protecting a critical section by disabling interrupts is
already thread-safe (and used in many places in RTEMS).
It might also be quicker/cheaper if it protects short sections
of code.

That said - I realize that interrupts were disabled across
malloc and free which is bad. I just fixed this.
> The BSP interrupt routines are declared in cpukit/include/rtems/irq.h 
> but don't follow the RTEMS naming conventions. A RTEMS interface for 
> interrupts would be nice?
>   
Oh yes - and a less clumsy one. The existing rtems_interrupt_catch
would be great *if* it supported a user argument to the isr...
> I found no place where the entry isOn from rtems_irq_connect_data is 
> used. We may remove it.
>   
Unfortunately, this would break all existing applications which
use the current API. This is IMO not a good idea.

It would be better to come up with a new API, deprecate the old
one and phase it out eventually.
> The MPC5566 evaluation board has only 128kB internal RAM. Due to the 328 
> interrupt sources the interrupt handler table is quite big: 7896 Bytes 
> (6% of internal RAM). The exception handler table is also not very small 
> with 896 Bytes (0.7% of internal RAM). Thus I want to introduce two new 
> defines BSP_CONFIG_CONSTANT_EXCEPTION_TABLE and 
> BSP_CONFIG_CONSTANT_INTERRUPT_TABLE and modify the code to support 
> constant tables.
>   
This defeats the whole 'new-exceptions' API which provides
methods to change raw exception handlers. Just playing
devil's advocate...

And how can a BSP with a constant interrupt table support
applications which use the calls to install/remove interrupt
handlers? You'd rather have to think of an alternative implementation
of the current API -- since probably most of the 328 sources
are unused e.g., a (smaller) hash table could be used and
the real 'rtems_irq_connect_data' structs be allocated only on demand.

In any case: prior to modifying code I suggest you make
proposals as to how the API must be changed and what
implementation you propose. Any implementation should
be generically useful rather than #ifdef dependent...

Cheers
-- Till
> Regards,
>     Sebastian
>
> --------------------------------------------
> embedded brains GmbH
> Sebastian Huber           Obere Lagerstr. 30
> D-82178 Puchheim          Germany
> Tel. : +49-89-18 90 80 79-6
> Fax  : +49-89-18 90 80 79-9
> email: Sebastian.Huber at embedded-brains.de
> PGP public key available on request
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>