From gcc-return-67665-listarch-gcc=gcc dot gnu dot org at gcc dot gnu dot org Thu Feb 06 23:40:04 2003 Return-Path: Delivered-To: listarch-gcc at gcc dot gnu dot org Received: (qmail 24840 invoked by alias); 6 Feb 2003 23:40:04 -0000 Mailing-List: contact gcc-help at gcc dot gnu dot org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner at gcc dot gnu dot org Delivered-To: mailing list gcc at gcc dot gnu dot org Received: (qmail 24600 invoked from network); 6 Feb 2003 23:40:01 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by 172 dot 16 dot 49 dot 205 with SMTP; 6 Feb 2003 23:40:01 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2 dot redhat dot com (8 dot 11 dot 6/8 dot 11 dot 6) with ESMTP id h16NY3105835; Thu, 6 Feb 2003 18:34:03 -0500 Received: from romulus.sfbay.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by int-mx2 dot corp dot redhat dot com (8 dot 11 dot 6/8 dot 11 dot 6) with ESMTP id h16Ne0n16645; Thu, 6 Feb 2003 18:40:00 -0500 Received: (from aldyh@localhost) by romulus dot sfbay dot redhat dot com (8 dot 11 dot 6/8 dot 11 dot 6) id h16Ndxn29479; Thu, 6 Feb 2003 15:39:59 -0800 X-Authentication-Warning: romulus dot sfbay dot redhat dot com: aldyh set sender to aldyh at redhat dot com using -f To: Jim Wilson Cc: Zack Weinberg , gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com Subject: Re: PPC E500 chip -- what are the -m switches supposed to be? References: <878ywtl0o1.fsf@egil.codesourcery.com> From: Aldy Hernandez Date: 06 Feb 2003 15:39:59 -0800 In-Reply-To: Message-ID: Lines: 69 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Jim" == Jim Wilson 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