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

[Aldy Hernandez <aldyh at redhat dot com>]

>>>>> "Jim" == Jim Wilson <wilson@redhat.com> writes:


  > 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

For that matter, as it stands, C++ EH doesn't work because the
unwinder expects registers to be 32-bits, but it should really be
saving all 64-bits.  When the Dwarf committee decides what is the
apprpriate thing to do, I'll work on fixing the unwinder and the e500
back end.

FYI, in the Red Hat toolchain, I just hardcoded the unwinder to expect
64-bit saves and restores.  Yucky, but temporary, and it works.

 > 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.

It started as booke, until everyone realized that was just a
misnomer.  The 8540 is the chip name, but I believe the correct name
is the E500.  SPE are the vector extensions.

 > 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.

Oh yeah, that.  Jim's definition is better ;-).

 > 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

Correct.

 > 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.

Yes, it should be added.  That way you can configure a default eabi
toolchain and pass -mspe and -mabi=spe to get SPE code.

 > 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.

Vacation?  I wish.  That comes later this month ;-).

 > 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.

I definitely need to revisit this.  Weren't there generic non-back-end
extensions to make this work?  If it all works with minimal generic
changes, I have no objections, considering what a pain it was to get
working.  (Provided you, or another global maintainer approves the
generic changes).

Aldy