Re: PPC E500 chip -- what are the -m switches supposed to be?

[Jim Wilson <wilson at redhat dot com>]

The e500 support is new, and should be considered bleeding edge.

Configure for powerpc-eabispe.  Then you get Book E code by default, including
spe extensions.

I doubt that you can get correct booke code from a regular powerpc toolchain,
that support hasn't been implemented yet.  There is an unresolved problem
dealing with mixed 32-bit/64-bit register saves/restores in the prolog/epilog,
and emitting correct DWARF2 CFI unwind info for them.  The booke ABI committee
is discussing how to resolve this.  So for the moment, you can only get
correct booke code from a toolchain configured to emit booke code by default,
and the code will not work on non-booke ppc hardware.

There does appear to be some room for improvement with the option naming.
I don't know the exact relationship between all of the terms here, 8540,
e500, Book E, spe, so I am not sure which option names are the right ones.
I think e500 is a processor core, Book E is the architecture name, 8540 is the
processor name, and spe is the name for the SIMD extension which is part of
the Book E architecture.

I don't believe that anyone has tried adding gcc support for Book E without the
spe extensions, which is what the gas -mbooke option is for.  Thus there is
no gcc support that matches this gas option.  This option seems misnamed,
since I thought spe was part of book e, but maybe it is reasonable to require
-mspe to get the spe support.

I believe we are planning to do some work to try to make it possible for
generic powerpc toolchains to emit booke code with an option.  Fixing the
option naming problem can perhaps be added to the list of things we are
fixing to get that working.  And documenting them too.

By the way, the booke specs were changing up until mid-December, and there
were critical bug fixes up until mid-December also.  The booke gcc port
should be considered bleeding edge at this time.  Red Hat testing was on an
internal branch.  I've tried testing the FSF tree.  There is at least one
critical bug fix patch that is missing from the FSF tree which shows up as
failures in the motorola spe testsuite.  I've pointed this out internally,
and Aldy was scheduled to fix it, but I think he spent January doing something
else (vacation perhaps?) so he hasn't gotten to it yet.

There also is at least one feature that is missing from the FSF tree, the
support for opaque vector types.  Without this support, you can't use the
spe.h header, and that means you can't use any of the intrinsics.  This
support was posted to one of the FSF lists a while ago (6 months ago?), but
Aldy never tried to get approval because he didn't think it was possible.
This needs to be revisited.  At the minimum, we need to provide this as an
add-on patch file somewhere in the FSF gcc tree to make the FSF gcc tree
usable.

Jim