From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1132 invoked by alias); 15 Nov 2011 17:43:40 -0000 Received: (qmail 1117 invoked by uid 22791); 15 Nov 2011 17:43:38 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 17:43:06 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 15 Nov 2011 17:43:03 +0000 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Nov 2011 17:43:01 +0000 Message-ID: <4EC2A4A5.2080008@arm.com> Date: Tue, 15 Nov 2011 17:43:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Joseph S. Myers" CC: Arnd Bergmann , "libc-ports@sourceware.org" , Catalin Marinas Subject: Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc References: <201111100054.pAA0sf6u025585@farm-0002.internal.tilera.com> <201111142216.54543.arnd@arndb.de> <6684568.qf2fzy7upl@wuerfel> In-Reply-To: X-MC-Unique: 111111517430302401 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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/msg00051.txt.bz2 On 15/11/11 16:14, Joseph S. Myers wrote: > Heavy limits to what's conditional actually remind me rather of Thumb-1.= =20=20 > Though with Thumb-1 you can and do move between ARM mode and Thumb mode a= t=20 > runtime (and in principle attributes to compile some functions as ARM and= =20 > others as Thumb would make sense) which is not something that makes so=20 > much sense for 32-bit and 64-bit modes. So there's more conditional execution than thumb-1 (which was essentially conditional branches), but a lot less than thumb-2. > If NEON (Advanced SIMD) is similar to 32-bit, perhaps that (being one of= =20 > the more recent additions to the 32-bit architecture) would be one of the= =20 > more plausible areas for sharing code (possibly sharing generators like=20 > for Tile rather than generated code). Again, there's a similar flavour, but the mnemonics are different. Also the register architecture in the FP/SIMD space is different between 32-bit and 64-bit execution states. We're expecting to keep compatibility for the vector intrinsics, but not for assembly language -- another reason not to try to use inline assembly in your code for doing neon stuff. > (It would be generically desirable to be able to have a single GCC,=20 > binutils etc. build supporting multiple targets with a --target=3D or=20 > similar option to select between them, whether or not those targets share= =20 > a back end in their implementations. But as I discussed at=20 > that would be a= =20 > lot of work, whereas wrappers round two separate compiler builds are very= =20 > simple - so genuinely multi-target compilers become more relevant if you= =20 > want a single source file to contain functions for different architecture= s=20 > - which adds its own complications, although GDB does support different=20 > call frames being on different architectures.) >=20 It's easy enough to produce a generic linker/librarian/objdump; but much harder for things like the assembler. For the compiler the overlap is very small -- essentially limited to wanting to share some pipeline descriptions, but there's no reason why that can't be done without having to share the entire back-end. I think genuinely mixed back-ends will have to wait until such time as the target vector is truly switchable at run time. R.