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

ppc multlibs and BSP removal was Re: powerpc altivec support



Ralf Corsepius wrote:
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.

In this case newlib actually uses an Altivec conditional. At the moment, RTEMS knows nothing about Altivec. As Till mentioned, t seems to imply some alignment requirements. Which is a multilib level issue.


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.

This is a real issue on the powerpc and mips. There are LOTs of odd variant CPUs and it is hard to make generic statements.


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 think old exception process is now done to 4xx and a few 6xx BSPs.
I know of one old exception 6xx BSP which is in use and needs to be updated. They have offered to do the conversion but that project has been up to its eyeballs the past 6 months and has barely made deadlines close enough to keep managment happy on required tasks. If someone can mechanically update it to the new exception model, I will be happy to
merge that and kill the 6xx BSPs.


I might even be willing to consider killing all the old exception 6xx BSPs except that and quit building it for a while.

Till.... if you could do that mechanically, it would kill some multilibs. and leave old exception processing on

Ralf.. at a quick glance.  I THINK the following variants multilibs are
up for discussion:

  + m821 and m860 -- these are equivalent and equal "mppc".  Mapping
    both to another multilib and kill.
  + All 601 and 602 variants should be dead.  Can someone comment.
  + Can mpc8260 should be mapped to a 603e variant AFAIK.
  + Ralf.. is the default multlib the same as 603?

I guess I am seeing that some of the variants could be overkill. The same core is used in lots of CPUs. Can we analyze each multilib and justify its existence?

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.

I think we can kill more than enough to make it possible to add.

GCC thinks a lot of -mXXX are -mppc internally anyway and RTEMS PROBABLY
doesn't care until you get to libcpu and libbsp.

--> 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 :(

This always confused me.

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>

Can you put this in the WIki somewhere?

Ralf




--
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985