[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: powerpc altivec support



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