ppc multlibs and BSP removal was Re: powerpc altivec support

[Joel Sherrill <joel@OARcorp.com>]

I know this is going to stir up some discussion BUT here goes nothing.

Is there anyway that the PowerPC exception code can be general up to
a certain point and then invoke a BSP specific routine to peek for other 
interrupts?  The MIPS has a general handler code which does general
register saving and then invokes a method provided by the CPU model or 
BSP to figure out the interrupt source.

This allows  sharing the complicated assembly code and provides a 
standard hook to decode PICs.  The vector decoding source can be in C or 
assembly.  On the MIPS this is nice since some of the decoding source is
complicated.  It is a tad bit slower but worth it for maintenance.

Alternatively, is there a standard prologue and epilogue that could be 
split off into separate files so we end up with:

#include STANDARD PROLOGUE
   BSP specific code which must meet certain requirements
#include STANDARD PROLOGUE

I can even see having a standard middle for simple targets.

This is technically simpler since all we are doing is mechanically 
extracting the common entry and exit.  It should be less likely to break 
anything.  Can this be done?

--joel



Till Straumann wrote:
> Sergei Organov wrote:
> 
>> "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
>>  
>>
>>> Could you submit a patch for the issues you comment on in this email?
>>> If it is for a BSP you can't test, I am happy if you will make a good
>>> faith attempt with a desk check and it compiles.
>>>   
>>
>>
>> Well, below is the patch for _CPU_Install_interrupt_stack() in the
>> old exception processing.
>>
>> As for the r2/r13 loading by the new exception processing code, sorry,
>> but I leave it as an exercise for those who believe new exception
>> processing is better than the old one. Let them change at least 5
>> separate files with almost identical code. Well, if somebody believes
>> something is inherently broken with such an approach to the software
>> development, ask Eric Valette about it, or just read what he answered to
>> a similar question before:
>>
>> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00167.html> 
>>
>>
>> Besides, when I've raised that same question (r2/r13 loading in ISR)
>> before, I've been told that it's not a problem as all the code in the
>> executable must be strictly EABI/SYSV ABI compatible, and if some code
>> is not, it should be fixed anyway.
>>
> The "new" exception model assembly code *itself* violated EABI 
> clobbering r2. A while ago I went through all
> this and fixed 'libbsp/powerpc/shared/irq/irq_asm.S' [a snippet in PR#349].
> 
> BTW: as I write this, I realize that I didn't care about the other BSPs 
> and as a consequence of the
> chaotic 'copy/paste' design of the 'new' exception handling stuff the 
> bug is STILL PRESENT
> [filed as PR#759] The ISR assembly code saves/restores r2 across the ISR 
> but clobbers r2 itself so the
> C-ISR sees a corrupted r2...
> 
>> Though the question how to find and
>> identify a piece of code that is not compatible has been left
>> unanswered.
>>
> powerpc-rtems-objdump -dr   librtemsbsp.a | grep '[^(]\<r2\>'
> 
> brings you close to critical points.
> 
>>
>> Overall, this code has been intentionally removed from the new exception
>> processing code and I don't feel myself in charge of returning it back.
>>
>> If you use new exception processing, better make sure no code in your
>> executable tries to change r2/r13 even temporarily while interrupts are
>> enabled.
>>
>> I prefer to be on the safe side, so I stay with the old one for
>> now.
>>
> I guess I don't really have a choice - it would be wonderful to have a 
> better solution
> (especially for the IRQ and [nonexistent exception] API) but I don't 
> have the resources
> to solve this.
> 
> -- Till
> 
>>
>>  
>>
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985