[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ppc multlibs and BSP removal was Re: powerpc altivec support


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@OARcorp.com>" <joel.sherrill@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@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985