powerpc altivec support

[Till Straumann]

Ralf Corsepius wrote:

>On Tue, 2005-02-08 at 15:52 -0800, Till Straumann wrote:
>  
>
>>Hi.
>>
>>I'm looking into ALTIVEC support for RTEMS along the lines of
>>lazy FP context switching. However, I'd like to hide this from
>>SCORE code for obvious reasons. OTOH, it seems also ugly
>>to switch the vector registers as a side effect of CPU_Context_switch().
>>
>>Any suggestions?
>>
>>Ralf: what needs to be done to get an altivec enabled toolchain and
>>newlib for the CPU variants that support it?
>>    
>>
>Basically, by adding appropriate multilib variants to GCC.
>
>In general have to prove that such a multilib variant actually makes
>sense (gives a measurable improvement in performance) 
>and can not be avoided by other means.
>
As far as I could see, lack of an altivec variant has the following 
implications:

 - libgcc doesn't use altivec --> only a possible stack misalignment
 - newlibc setjmp/longjmp would not save/restore the altivec registers 
-> BAD
 - newlibc vfprintf() would not support vector formats -> undesirable

==> if we added altivec support to RTEMS [very desirable for 
number-crunching
         applications], we certainly need a newlibc with altivec support.

         The good news is, however, that the newlibc code (essentially 
setjmp/longjmp)
         which needs a small __rtems__ patch anyways could perform a 
quick run-time
         check for altivec, i.e., altivec could essentially be enabled 
for any ppc variant
         (or at least 7400++).

>
>However, due to the number of multilib variants being used by the
>powerpc, convincing me to add another one to powerpc-rtems-gcc will be
>extraordinarily tough.
>  
>
>
>  
>
>>BTW: I see in gcc/config/rs-6000/t-rtems (gcc-3.2.3 / rtems-4.6) that
>>           "no-eabi" is passed to all PPC variants (MULTILIB_EXTRA_OPTS)
>>           -- this might be out of sync, as EABI is the default PPC abi for
>>           RTEMS
>>    
>>
>
>Is it? That's news to me, but ...
>
>cf. http://www.rtems.org/cgi-bin/gnatsweb.pl?cmd=view&pr=195
>
>... nobody ever has been able to sort this out.
>  
>
Looks like chicken + egg.

BTW: mno-eabi probably doesn't really have a great impact as this 
effectively only
           changes the stack alignment. The really interesting thing 
could be
           enabling both 'meabi' and 'msdata=eabi'. This would improve 
both, space
           *and* speed efficiency.

OTOH, I totally agree that there are too many possible and useful variants.

I'd propose to discuss doing away with some of the 604 compatible variants
- probably, just one of them would be enough, e.g.:

a) 604 with no altivec
b) 7400 with altivec

--> AFAIK, a) can be run on anything from 604..7400 (assume gcc/newlib needs
       only the UEA)
--> applications with need for altivec can use b)

Also, I don't see the benefits of a soft-float variant for all of the 
604++ machines
(maybe that applies to pre-604 also, I just know 604++ best).

OTOH, having a few 'msdata=eabi meabi' variants would be useful.

Baseline: IMO, the number of pre-built variants should be cleaned up AND
                  a HOWTO would be desirable for users wanting to build 
tailored toolchains.
                  An embedded board with low memory might significantly 
benefit
                  from meabi/msdata=eabi and a high end application 
might need
                  cpu=7450 maltivec mabi=altivec. The user should be 
assisted
                  generating a tailored toolkit

>
>  
>
>> [score/cpu/powerpc/rtems/score/ppc.h says:
>>    
>>
>[This file is obsolete, score/cpu/powerpc/rtems/score/powerpc.h has
>replaced it.]
>
>  
>
>>/*
>>*  Default to the EABI used by current GNU tools
>>*/
>>
>>#ifndef PPC_ABI
>>#define PPC_ABI PPC_ABI_EABI
>>#endif
>>]
>>
>>            and I believe nobody ever defines this to something else.
>>    
>>
>:-) Cf. http://www.rtems.org/cgi-bin/gnatsweb.pl?cmd=view&pr=195
>
>Ralf
>
>
>  
>