From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22749 invoked by alias); 15 Nov 2011 17:21:07 -0000 Received: (qmail 22710 invoked by uid 22791); 15 Nov 2011 17:21:03 -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:20:26 +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:20:23 +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:20:21 +0000 Message-ID: <4EC29F55.9050906@arm.com> Date: Tue, 15 Nov 2011 17:21: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: Arnd Bergmann CC: "Joseph S. Myers" , "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: <6684568.qf2fzy7upl@wuerfel> X-MC-Unique: 111111517202305201 Content-Type: text/plain; charset=UTF-8 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/msg00050.txt.bz2 On 15/11/11 05:37, Arnd Bergmann wrote: > On Monday 14 November 2011 23:38:36 Joseph S. Myers wrote: >> On Mon, 14 Nov 2011, Arnd Bergmann wrote: >> >>> The armv8 code base is currently separate from the 32 bit arm in both k= ernel >>> and gcc, I assume the same is true for glibc. I would like to keep it t= his >> >> Are you able to post those patches somewhere? Please be patient. One of the key reasons for announcing the architecture at this time was so that we could start the process of engaging with the community. There's a lot to do in terms of sorting out both logistics and legals and it's often easier if that can be done without having to sort out horrible things like 3-way NDAs. I can say that ARM has been working on ports of the key elements needed to support the architecture and that in due course I expect these will be released to the community; but it's not going to be today, or even next week. >=20 > Unfortunately not. I don't have have the code myself yet, but I am in > close contact with the developers. To my knowledge, all the publically > available information is under > http://www.arm.com/products/processors/technologies/instruction-set-archi= tectures.php?tab=3DARMv8+Resources > which is unfortunately very little at the moment. >=20 >> I hope that if it's as different as you say (that is, "ARM" only in=20 >> marketing terms, not in terms of similarity to anything previously calle= d=20 >> ARM), the GNU target triplet for 64-bit mode is not armv8*-*-* or anythi= ng=20 >> else starting with "arm", given that would match any number of cases all= =20 >> over the place that test for arm*-*-*.... armv8*-*-* should clearly be = v8=20 >> in the normal 32-bit mode. >=20 > Richard Earnshaw should be able to tell you more about this. I don't know > what the triplet will be, but I assume the developers are aware of the pr= oblem > you mentioned. >=20 Using armv8 as the triplet would be completely wrong. First off, ARMv8 is just the next iteration of the architecture; it's not revealing anything to say that one day I would expect there to be an ARMv9, an ARMv10 and so on... I would expect all of these to continue to support the 64-bit architecture. 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 and rename the existing ARM port to use aarch32; though obviously there's no chance of doing that now. >>> way for the kernel, because the syscall ABI, the ELF ABI and the instru= ction >>> set are all very different from ARM, while there is very little code th= at >> >> Are the ABI and ISA specifications available somewhere? I couldn't find= =20 >> them. >=20 > No. I hope that these will be made available to some upstream glibc and g= cc > maintainers at the same time that I and other kernel people get access > to kernel patches, with public code review some time after that. > Richard or Catalin can probably arrange for you to be in the early review > team if you are interested. 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. >=20 >>> can actually be shared. In gcc, the tradeoff apparently is similar, and >>> I don't expect them to change that either. If we ever get a -m32/-m64 s= witch >>> on armv8, that is more likely to use only the full 64 bit instruction s= et >>> with either a ILP32 or LP64 ABI, but not the old instruction set. >> >> How dissimilar are the instruction sets? The obvious comparison is SH64= -=20 >> which uses the same GCC back end and arch/ directory in the kernel, but= =20 >> where some people have suggested there is sufficiently little similarity= =20 >> to other versions of SH that having a separate back end would have been= =20 >> better. Unfortunately I don't know enough about SH to judge that for=20 >> myself. (The Score port of GCC was an example that clearly did not belo= ng=20 >> in one back end; until support for an older ISA variant was removed, all= =20 >> the main hooks just selected at runtime between functions for two=20 >> different instruction sets. If the instruction sets are so different th= at=20 >> every function is just if (32-bit) 32-bit-func (); else 64-bit-func ();,= =20 >> with nothing useful to share, then you definitely want two separate=20 >> ports.) >=20 > The public PDF lists >=20 > "Instruction semantics broadly the same as in AArch32 > =EF=83=AC * Changes only where there is a compelling reason to do so" >=20 > and >=20 > =EF=83=AC "Far fewer conditional instructions than in AArch32 > * Conditional {branches, compares, selects}" >=20 > My understanding is that it would be possible to do a combined port, > but that the second part makes that rather impractical. 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. As such, we've seen no killer reason to date for developing a unified compiler back-end. >=20 >> If ARMv8 supports the classic ARM and Thumb-2 instruction sets for 32-bi= t=20 >> code and if those have any new features compared to ARMv7, that of cours= e=20 >> implies supporting ARMv8 properly includes support for those new feature= s=20 >> in 32-bit code with the 32-bit back end (after all, you want to be able = to=20 >> build code that dynamically dispatches based on the processor in use at= =20 >> runtime, whether with STT_GNU_IFUNC or otherwise, so want one compiler t= o=20 >> support a range of 32-bit code generation from v4 through v8). >=20 > Quoting from that document again >=20 > "Enhancement to the AArch32 functionality > =EF=83=AC * Relatively small scale additions reflecting demand > * Maintaining full compatibility with ARMv7" >=20 > So there would be some changes to the existing code, but it does not > sound like there is much to share here with the new AArch64 code. Yes, there are a small number of extensions to the 32-bit ISA; but I don't think I can talk about the details at present, sorry. >=20 >> I suppose a key question is whether the 64-bit ISA has entirely new=20 >> instructions - not just a new encoding of largely existing instructions= =20 >> like Thumb-2 was - in which case separate ports likely make sense - or=20 >> whether it has a large proportion of the old instructions with their=20 >> semantics changing in predictable ways that can be abstracted=20 >> appropriately in the compiler. (There is also the possibility of being= =20 >> able to share some code between separate ports, as with the Tilera ports= -=20 >> similar enough to share a lot of code in glibc and a smaller amount in G= CC=20 >> (a shared generator for some tables that are different in the two ports)= ,=20 >> but different enough to count as different targets.) >=20 > 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 instruct= ions, > so there is just very little that remains common. >=20 With no-interworking, different register assignments, different ABI, different register sizes and different instruction sets there's almost no reason at all for having a single toolchain (the only minor reason raised so far is trying to build a VDSO that a 64-bit kernel can supply to 32-bit apps -- but there are other ways to deal with that). >> Presumably the actual patch submissions will come with clear rationale f= or=20 >> the approach taken, given that the recent Linux kernel trend has been to= =20 >> unify formerly separate directories for 32-bit and 64-bit variants (and= =20 >> MMU / no-MMU) of the same architecture, e.g. x86 unifying i386 and x86_6= 4.=20=20 >> An ia16 port for GCC was also rejected because of a general view that it= =20 >> would better be a -m16 mode in the i386 back end. I don't think there a= re=20 >> any existing GCC ports for which the 32-bit and 64-bit instruction sets= =20 >> use different ports, and I think PA is the only one with 32-bit and 64-b= it=20 >> variants but without -m32/-m64 options to choose between them (instead=20 >> requiring separate compilers for the two modes) - and that is probably=20 >> because 64-bit PA GNU/Linux hasn't got very far, while HP-UX uses=20 >> different object formats for 32-bit and 64-bit which makes a unified=20 >> compiler for those variants hard to achieve. Well, technically IA64 contains an implementation of x86, but there is no shared compiler between the two. I've never seen anybody clamouring for those compilers to be merged. >=20 > Regarding the kernel I was also very skeptical at first, given that I have > spent a lot of time unifying the code for s390/s390x, ppc/ppc64 and > i386/x86_64. My feeling now is that adding a new arch port to the kernel > is fairly lightweight in comparison to making a significant change to the > arch/arm directory that is already the most complex one we have and > happens to be in the middle of a major restructuring. Almost all the code > that I expect to be shared in the end is stuff that we are moving into > architecture independent drivers, e.g. interrupt controllers, > timers etc, since those are often shared with other architectures like > ppc, sh or hexagon anyway. The non-driver parts (32-bit syscall list, > lpae page table format, ...) that we may want to share can probably use > tricks similar to what you mentioned for the tile gcc port. I'll leave any rationale on kernel structure and re-organization to those who know the code better than I do. R.