This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PPC E500 chip -- what are the -m switches supposed to be?
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Jim Wilson <wilson at redhat dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: 06 Feb 2003 15:39:59 -0800
- Subject: Re: PPC E500 chip -- what are the -m switches supposed to be?
- References: <878ywtl0o1.fsf@egil.codesourcery.com><xwu4r7hkrpo.fsf@tonopah.toronto.redhat.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