Altivec Context Management

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