From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1830 invoked by alias); 15 Nov 2011 17:45:21 -0000 Received: (qmail 1818 invoked by uid 22791); 15 Nov 2011 17:45:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 17:44:41 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RQN3o-000151-5w from joseph_myers@mentor.com ; Tue, 15 Nov 2011 09:44:40 -0800 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2011 17:44:38 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1RQN3l-0002ca-EC; Tue, 15 Nov 2011 17:44:37 +0000 Date: Tue, 15 Nov 2011 17:45:00 -0000 From: "Joseph S. Myers" To: Richard Earnshaw cc: Arnd Bergmann , "libc-ports@sourceware.org" , Catalin Marinas Subject: Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc In-Reply-To: <4EC29F55.9050906@arm.com> Message-ID: References: <201111100054.pAA0sf6u025585@farm-0002.internal.tilera.com> <201111142216.54543.arnd@arndb.de> <6684568.qf2fzy7upl@wuerfel> <4EC29F55.9050906@arm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00052.txt.bz2 On Tue, 15 Nov 2011, Richard Earnshaw wrote: > The triplet we've been using internally is based on 'aarch64' as the > first component; I see no reason why we shouldn't adopt that as the > standard name, thus aarch64-none-linux-gnu would become the standard > 'triplet' for Linux. If I could rewrite history, I'd probably go back That seems good to me. (With the possibility of variants such as aarch64b to describe a toolchain that's configured to be big-endian by default.) > and rename the existing ARM port to use aarch32; though obviously > there's no chance of doing that now. Just as renaming i386 to ia32 in target triplets wouldn't make sense either. > The ISA is not public yet; some more details will be released in due > course. The ABI specs, however, are already downloadable from > infocenter.arm.com in the usual place. Thanks, I'll have a look at those. I see IHI0055A_aapcs64.pdf, IHI0056A_aaelf64.pdf, IHI0057A_aadwarf64.pdf, IHI0059A_cppabi64.pdf - is it expected analogues to the other parts of the 32-bit ABI will be released when ready, or are they all included in those four documents? > First you have to remember that there's no call-level interworking > between the 32-bit and 64-bit states: you can only switch states at an > exception level boundary. Secondly, although the new ISA is 'ARM > flavoured' it is very definitely different to the AArch32 (ie ARM and > Thumb) and I don't expect there will be any attempt to create a new > 'unified' syntax between the two: the number of cases where you could > share assembly files is just too limited. So substantially more different than x86 and x86_64, then (which in turn are substantially more different than 32-bit and 64-bit variants of MIPS, say, where assembly files really do get shared using macros to abstract the differences). -- Joseph S. Myers joseph@codesourcery.com