Re: Altivec Context Management

["Joel Sherrill <joel at OARcorp dot com>" <joel dot sherrill at OARcorp dot com>]

Ralf Corsepius wrote:
> On Fri, 2005-11-04 at 08:16 -0600, Joel Sherrill  wrote:
>
>
> > + Add Altivec multilib
> >
> >   If we have extra registers which gcc is aware of, this forces our hand
> >   and it adds a multilib.
>
> We already have this multilib.
>
> -mcpu=7400 implies altivec, all others don't.

Sorry I missed that piece of knowledge.  Then RTEMS should just honor 
the __ALTIVEC__ flag which is set when -mcpu=7400 is set.  It will 
require no tool changes for gcc 4.0.x.

The gcc version for 4.6 does not set __ALTIVEC__ when -mcpu=7400 is 
specified.

> I.e. if -maltivec is a problem to RTEMS and some BSPs, you should use a
> different -mcpu=<cpu>. If this is not possible, the powerpc port in
> RTEMS is facing a the limitations of its design.

> IMO, a separate -maltivec multilib variant doesn't make without a major
> redesign of the powerpc port. 

It doesn't sound like the multilib variant is needed as long as 
-mcpu=7400 is really the correct CPU model CFLAG for the BSPs/CPU models 
in question.

But RTEMS does need to honor the __ALTIVEC__ flag and based upon gcc's 
use of the vector registers, this would mean it is part of the basic 
integer context when available.

> >   Whether this should be done for 4.6 tools is up for discussion but it
> >   is clear that gcc 4.0.x and newer definitely will have to ship with
> >   Altivec multilibs for RTEMS.
>
>
> cf. above.

They already do.  RTEMS itself just needs to honor Altivec.

Good.. one less piece to deal with.

> Ralf


--
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