[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:As far as I could see, lack of an altivec variant has the following
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().
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.
- libgcc doesn't use altivec --> only a possible stack misalignment
- newlibc setjmp/longjmp would not save/restore the altivec registers
- newlibc vfprintf() would not support vector formats -> undesirable
==> if we added altivec support to RTEMS [very desirable for
applications], we certainly need a newlibc with altivec support.
The good news is, however, that the newlibc code (essentially
which needs a small __rtems__ patch anyways could perform a
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
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
Is it? That's news to me, but ...
... 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
changes the stack alignment. The really interesting thing
enabling both 'meabi' and 'msdata=eabi'. This would improve
*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
(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
An embedded board with low memory might significantly
from meabi/msdata=eabi and a high end application
cpu=7450 maltivec mabi=altivec. The user should be
generating a tailored toolkit
[This file is obsolete, score/cpu/powerpc/rtems/score/powerpc.h has
* Default to the EABI used by current GNU tools
#define PPC_ABI PPC_ABI_EABI
and I believe nobody ever defines this to something else.
:-) Cf. http://www.rtems.org/cgi-bin/gnatsweb.pl?cmd=view&pr=195