ppc multlibs and BSP removal was Re: powerpc altivec support

[Ralf Corsepius]

On Wed, 2005-02-09 at 06:40 -0600, Joel Sherrill  wrote:
> 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:

>    + 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?
No, the default is identical to the -m750.

> 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?
The problem is the powerpc port in RTEMS, not newlib nor GCC. Many of
these multilib variants share the same ISA/ABI etc. but they do not
share the same code in RTEMS 
(cf. cpukit/score/cpu/powerpc/rtems/score/cpu.h)

> >>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.
Unfortunately nothing could be further from the truth than this, as far
as the powerpc is concerned - It is the design issue/flaw I have been
repeatedly referring to.

cpukit/score/cpu/powerpc/rtems/score/cpu.h is ca. 700 lines in size,
scattered with ca 30 different defines, which all are candidates for
conditionally compiling something somewhere. The problem there is to
identify which are actually important and which are not.

Try to track how *ALIGNMENT defines are set up and you'll probably
experience what I am referring to.

Ralf