Altivec Context Management
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Fri Nov 4 17:27:36 UTC 2005
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
> 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:
set_masks &= ~MASK_ALTIVEC;
Not particularly useful. An automated version of "don't do that, it
hurts." I would rather fix the problem.
More information about the users