Support for PowerPC e200 cores

[Ralf Corsepius]

On Fri, 2008-02-15 at 08:33 -0800, Till Straumann wrote:
> FWIW, I strongly recommend to abandon the current
> PPC multilib mess.
So would I, but ... the cause for this mess is RTEMS design, not in GCC.

RTEMS design is based on "cpu-variants", not on "instruction set
variants", which would harmonize better with multilibs.

> Currently, the main reason for the many variants is that
> rtems' gcc specs map the -mcpu=xxx flags to a corresponding
> -DXXX which is tested in rtems libcpu and libbsp code.
Almost, ... these -Dxxx are being used in cpukit's cpu.h.

We would have to eliminate/rebase them, to get rid of the multilib
variants.

> However, this can also be achieved by the BSP's
> custom/<bsp>.cfg fragment adding -DXXX.  It would even
> be better to eliminate this kind of conditional compilation.
No. *.cfg's aren't applicable/used when building RTEMS multilib'ed.

> >> Finally, trying to add it (it's one multilib variant) reveals bugs in
> >> GCC -- If it was that easy, I would have posted a patch in response ;)
> >>   
> >>     
> > OK.  I guess it's time to start filing PRs again and seeing
> > if Debian or Fedora is holding another lump of unsubmitted
> > patches that  look to help.
The issue being triggered in GCC when adding an -mcpu=8540 multilib to
GCC is a clash between the default GCC-flags (implying hard-float) and
GCC's e500 instruction set (not supporting hard-float).

So, technically, one would have to find a way, to override the current
default GCC-flags with an e500-compliant set of flags for -mcpu=8540. 

Unfortunately, the powerpc-port in GCC is such kind of overloaded,
implementing this is far from being trivial.

Ralf