From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2399 invoked by alias); 15 Nov 2011 17:46:58 -0000 Received: (qmail 2384 invoked by uid 22791); 15 Nov 2011 17:46:56 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.186) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 17:46:24 +0000 Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MNhBG-1RWRta2VNS-007Vbp; Tue, 15 Nov 2011 18:46:16 +0100 From: Arnd Bergmann To: "Joseph S. Myers" , Ulrich Weigand Subject: Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc Date: Tue, 15 Nov 2011 17:46:00 -0000 User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; ) Cc: libc-ports@sourceware.org, Richard Earnshaw , Catalin Marinas References: <201111100054.pAA0sf6u025585@farm-0002.internal.tilera.com> <6684568.qf2fzy7upl@wuerfel> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111151746.12872.arnd@arndb.de> 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/msg00053.txt.bz2 On Tuesday 15 November 2011, Joseph S. Myers wrote: > On Tue, 15 Nov 2011, Arnd Bergmann wrote: > > > I suppose a key question is whether the 64-bit ISA has entirely new > > > instructions - not just a new encoding of largely existing instructions > > > like Thumb-2 was - in which case separate ports likely make sense - or > > > whether it has a large proportion of the old instructions with their > > > semantics changing in predictable ways that can be abstracted > > > appropriately in the compiler. (There is also the possibility of being > > > able to share some code between separate ports, as with the Tilera ports - > > > similar enough to share a lot of code in glibc and a smaller amount in GCC > > > (a shared generator for some tables that are different in the two ports), > > > but different enough to count as different targets.) > > > > I think the answer is that the 64 bit ISA removes most of the baggage of > > the ARMv1 through ARMv7 legacy while adding the necessary 64 bit instructions, > > so there is just very little that remains common. > > So maybe more like SH64 than x86_64, then. Yes, but it unlike sh64 it would still run as LP64 in Linux initially, though an ILP32 ABI could be added later. > If NEON (Advanced SIMD) is similar to 32-bit, perhaps that (being one of > the more recent additions to the 32-bit architecture) would be one of the > more plausible areas for sharing code (possibly sharing generators like > for Tile rather than generated code). SIMD instructions are integrated into the base instruction set on v7, not using the coprocessor extensions like neon, which could make the instruction format too different for this even if the execution units are shared with NEON. > (It would be generically desirable to be able to have a single GCC, > binutils etc. build supporting multiple targets with a --target= or > similar option to select between them, whether or not those targets share > a back end in their implementations. But as I discussed at > that would be a > lot of work, whereas wrappers round two separate compiler builds are very > simple - so genuinely multi-target compilers become more relevant if you > want a single source file to contain functions for different architectures > - which adds its own complications, although GDB does support different > call frames being on different architectures.) I've discussed this before with Uli Weigand, and I think it would be very useful to have a multi-target toolchain support, but if I understand your proposal correctly, you are thinking of a more fundamental version that actually has a single cc1 binary with support for multiple targets. I was hoping that we could fix the -b command line option and add proper support in the build system to build multiple separate sets of target binaries with a shared driver, but I now saw that the option has been removed as of gcc-4.6, presumably for good reasons. Arnd