Altivec Context Management

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Fri, 2005-11-04 at 10:25 -0600, Joel Sherrill  wrote:
> 

> The magic is deeply hidden in GCC's sources:
> 
> Check gcc-4.0.x/gcc/config/rs6000/rs6000.c for POWERPC_7400_MASK.

Yep.  It turns on Altivec.

>>  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 current don't have such a toolchain at hand, but if I recall
> correctly, it didn't have an -mcpu=7400 multilib variant ;)

I lean to fixing this in 4.6 by saying "don't do that".

> Checking GCC-3.4's source code however indicates that -mcpu=7400 already
> implied -maltivec and -D__ALTIVEC__ in gcc-3.4. This matches with my
> memory, because I believe altivec had been introduced in gcc-3.4 and
> then more or less completely rewritten for gcc-4.x).

Apparently since it really uses them now. :)

> It's the old problem with powerpc port:
> powerpc-RTEMS classifies its internals on "cpu-variants", while GCC is
> on the move towards classifying its internals on "cpu-features".

There is no legacy with this issue.  The context switch code just needs 
to honor Altivec.

I hope we decide the interrupt code doesn't need serious work.  If it 
does, we may be in for some refactoring and combining.  It is needed anyway.

>>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.
> 
> 
> I recall we had a discussion on this topic when gcc-4.0 ca. at the time
> when about to be released or just released. The result of this
> discussion was to add an m7400 multilib variant.

Good.  Then we laid the groundwork and now we know what follow up to do.

> BTW: Check gcc-4.0.x/gcc/config/rs6000/rs6000.c for OS_MISSING_ALTIVEC.
> I didn't try to investigate what it actually is, but it's looks like it
> probably related to the RTEMS altivec problem

It appears to just disable it:

#ifdef OS_MISSING_ALTIVEC
   if (OS_MISSING_ALTIVEC)
     set_masks &= ~MASK_ALTIVEC;
#endif

Not particularly useful.  An automated version of "don't do that, it 
hurts." I would rather fix the problem.

--joel