Multilib swamp

Ralf Corsepius ralf.corsepius at
Thu Mar 3 06:25:45 UTC 2005

On Wed, 2005-03-02 at 09:50 -0800, Till Straumann wrote:
> Ralf Corsepius wrote:
> >On Wed, 2005-03-02 at 06:36 -0600, Joel Sherrill  wrote:
> >
> >  
> >
> >>I know TIll and I are being non-committal here but the perfect decision
> >>varies based upon the code in question, when it is executed. and when it 
> >>can vary.  Untested or untestable code is obviously bad.  Creating
> >>multilib variants is even worse.  Given that this is an initialization
> >>issue, I would lean to dynamic checking -- this code ends up under
> >>libbsp anyway.
> >>    
> >>
> >You don't need dynamic checking, if the code "ends up under libbsp". You
> >can add the code to libcpu or to the bsp in both cases and add
> >appropriate defines to bspopts.h or to CFLAGS to conditionally enable
> >it.
> >
> >If you feel you need to use the code under cpukit, add appropriate
> >definitions ("extern functions" -- API!) to cpukit and implement these
> >functions into libcpu or the BSP.
> >
> >The rule of thumb is: You must not add defines to cpukit/score, unless
> >inevitable.
> >  
> >
> Brings me right back to the question I asked originally - how could we 
> best add hooks for
> altivec register context switching [ without introducing an ugly #ifdef 
> __PPC__ into cpukit]?
> Ideas?

I am not sure if I understand your problem.

AFAIU, your problem seems to be that you want to add additional
"altivec" registers to the powerpc's context switch.

My answer depends on your definitions of "altivec".

GCC's internal #define __ALTIVEC__ means GCC is using "altivec"

So one way to achieve adding "altivec registers" would be to couple them
to "GCC using altivec instructions" (#ifdef __ALTIVEC__), and not
consider "altivec" otherwise.

As -maltivec/-D__ALTIVEC__ is only supported in GCC >= 4.0, this could
only work for GCC >= 4.0.

For GCC < 4.0, these "altivec registers" would not be available. With
GCC < 4.0 you'd end up using a "compatible instruction set" (mpc750) on
"altivec processors" with a multilib'ed cpukit.

If you'd want/need to use "altivec registers" with GCC < 4.0, i.e. not
using altivec instructions, but mpc750 instructions, you'd have to
resort to not using a multilib'ed cpukit then. You could resort to using
one of the mpc74xx defines being using in
cpukit/score/cpu/powerpc/rtems/score/powerpc.h then.
Another approach would be to actually try adding "libcpu hook functions"
to context switches, but .. I fear this could easily become very
difficult and error prone, actually I don't expect this to be doable.


More information about the users mailing list