Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Eric Valette]

Sergei Organov wrote:

> Non standard? Hmm... I'd call PPC EABI the natural standard for embedded
> applications... If it's not standard for PPC port of RTEMS, it's failure of
> the port, I believe. Besides, old exception processing code did handle it fine.

Just wanted to say that code in rtems with the actual compilation flags 
was working. You triggered a bug by using compilation flags different 
than the one in the BSP...


> I believe the problem is not in autoconf/automake files. The problem is that
> the code in shared/irq_asm.S is not parametrized by CPU features as the old
> exception code was. Because of this BSP writers seem to take simple way of
> making a copy of the file and making required small changes in the copy.

I disagree : having nested ifdefs make code hard to understand and 
maintains. Ifdefs are just different copy of code located in the same 
files...


>>	1) provide the On/Off/IsON handler that simplify the BSP code because
>>you have not to call the connect part and after that duplicate code to enable
>>the interrupt on the device, manage PIC, ...
> 
> 
> Sorry, I consider this to be more a drawback than an advantage. The extra
> level of abstraction in disabling/enabling/query interrupt status doesn't come
> without cost. For example, in my case it would replace about 3 asm
> instructions required to read/modify/store a hardware register with indirect
> function call through a pointer in the interrupt structure that even can't be
> inlined due to its indirect nature :-(

But we are speaking of code executed only at handler connexion!!! Many 
preople prefer to ahev no asm to write at all for handling irq...


> Also, connection of interrupt handler and enabling the interrupt are rather
> different activities, so I don't see where code is duplicated in the first
> place.

Each time you connect a vector, you need to code the actual manipulation 
of CPM/SIU bitmask to effectivelly enable the interrupt. What is the use 
of connecting a vector without effectively enabling the irq?

> Sorry, but this also seems to be a wrong approach for me. I doubt there exists
> generic algorithm that handles all the cases the way I need it. Just for
> example, what if I don't need to re-enable the IRQ once handler has been
> called as I have ISR handler that only posts a semaphore and then manage the
> hardware from inside a thread waiting on this semaphore. In this case
> re-enabling IRQ will result in forever loop as the device wasn't yet managed
> and thus didn't yet remove its interrupt request.

Use raw irq API and make whatever you want. Some interrupt do not even 
need to call the OS if processor stay masked...

> Also very frequently I don't need to enable an IRQ automagically after I've
> installed ISR handler to it. All this automatic handling just brings more
> troubles, IMHO.

Supply a nop in intrOn... What abig deal!!!

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette at free.fr