powerpc altivec support

[Ralf Corsepius]

On Tue, 2005-02-08 at 20:44 -0800, Till Straumann wrote:
> 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++).

If customizing newlib's code for --altivec is worth it (I don't know),
then somebody (you?) would have add this to newlib.

> >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.
IMO, the origin of this problem is RTEMS design. It encourages
optimizing for cpu-variants and forgets about data abstraction and
intentional suboptimality (My usual example: Nobody needs an i586+mmx
multilib variant, because an i586 will suffice in 99% of all cases. 

However, embedded folks do not seem wanting to accept similar
consideration on embedded processors :-( ).

Another, less general issue in this particular case is lack of knowledge
of the persons being involved. Everybody (including me) only knows about
a "subset of the big picture", but nobody knows "everything".
So, instead of cleaning up the mess, we are stuck with keeping up the
status quo and try hard not to change anything, because somebody insists
on something.

> 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.
Let me put it this way: We have full control over the ABI and ABI
details being used, and can change that at any time.

You (the powerpc-rtems users) would have to tell me or Joel, what kind
of ABI you prefer use. I see your BSPs using "-meabi -msdata=eabi", I
see other BSPs not using it. I see probably obsolete code in the
powerpc's cpu.h referring to other ABIs, I see RTEMS features (~itis?)
infecting cpu.h in general ...

... but I don't feel sufficiently knowledgeable on the powerpc
architecture to be able to resolve this knot.

As a consequence of this, my standard approach to resolving such ABI
issues is to question all requests for "non-defaults" CFLAGS and
requests for additions of multilibs

> OTOH, I totally agree that there are too many possible and useful variants.
Exactly - IMO, drastic measures would be justified.

E.g. I am not opposed to dropping one of the exception-processing
variants for rtems-4.7, even if this will upset some powerpc users.

> 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
Let me ask differently: Which altvec variants do you want to add?

In RTEMS/CVS, we already have a 7400 BSP. With GCC-4.0, -m7400 already
implies altivec. AFAIS, this BSP probably doesn't work when having been
built against a multilib'ed RTEMS. 
=> I see a demand (need?) for a -m7400/altivec multilib variant, but I
don't know if it is required or if this would be useful.

I don't know if altivec is useful for other powerpc-cpu-variants.

> --> 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.
I can't comment on these topics, others will have to comment on this :(

> 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
With GCC-4.0:

gcc/configure --target=powerpc-rtems<custom> --disable-multilib ...
make CFLAGS_FOR_TARGET=<custom-CFLAGS>

Ralf