This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc


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 kernel
>>> and gcc, I assume the same is true for glibc. I would like to keep it this
>>
>> 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.

> 
> 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-architectures.php?tab=ARMv8+Resources
> which is unfortunately very little at the moment.
> 
>> I hope that if it's as different as you say (that is, "ARM" only in 
>> marketing terms, not in terms of similarity to anything previously called 
>> ARM), the GNU target triplet for 64-bit mode is not armv8*-*-* or anything 
>> else starting with "arm", given that would match any number of cases all 
>> over the place that test for arm*-*-*....  armv8*-*-* should clearly be v8 
>> in the normal 32-bit mode.
> 
> 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 problem
> you mentioned.
> 

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 instruction
>>> set are all very different from ARM, while there is very little code that
>>
>> Are the ABI and ISA specifications available somewhere?  I couldn't find 
>> them.
> 
> No. I hope that these will be made available to some upstream glibc and gcc
> 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.

> 
>>> 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 switch
>>> on armv8, that is more likely to use only the full 64 bit instruction set
>>> with either a ILP32 or LP64 ABI, but not the old instruction set.
>>
>> How dissimilar are the instruction sets?  The obvious comparison is SH64 - 
>> which uses the same GCC back end and arch/ directory in the kernel, but 
>> where some people have suggested there is sufficiently little similarity 
>> to other versions of SH that having a separate back end would have been 
>> better.  Unfortunately I don't know enough about SH to judge that for 
>> myself.  (The Score port of GCC was an example that clearly did not belong 
>> in one back end; until support for an older ISA variant was removed, all 
>> the main hooks just selected at runtime between functions for two 
>> different instruction sets.  If the instruction sets are so different that 
>> every function is just if (32-bit) 32-bit-func (); else 64-bit-func ();, 
>> with nothing useful to share, then you definitely want two separate 
>> ports.)
> 
> The public PDF lists
> 
>  "Instruction semantics broadly the same as in AArch32
> ï * Changes only where there is a compelling reason to do so"
> 
> and
> 
> ï "Far fewer conditional instructions than in AArch32
>    * Conditional {branches, compares, selects}"
> 
> 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.

> 
>> If ARMv8 supports the classic ARM and Thumb-2 instruction sets for 32-bit 
>> code and if those have any new features compared to ARMv7, that of course 
>> implies supporting ARMv8 properly includes support for those new features 
>> in 32-bit code with the 32-bit back end (after all, you want to be able to 
>> build code that dynamically dispatches based on the processor in use at 
>> runtime, whether with STT_GNU_IFUNC or otherwise, so want one compiler to 
>> support a range of 32-bit code generation from v4 through v8).
> 
> Quoting from that document again
> 
>  "Enhancement to the AArch32 functionality
> ï * Relatively small scale additions reflecting demand
>   * Maintaining full compatibility with ARMv7"
> 
> 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.

> 
>> 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.
> 

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 for 
>> the approach taken, given that the recent Linux kernel trend has been to 
>> unify formerly separate directories for 32-bit and 64-bit variants (and 
>> MMU / no-MMU) of the same architecture, e.g. x86 unifying i386 and x86_64.  
>> An ia16 port for GCC was also rejected because of a general view that it 
>> would better be a -m16 mode in the i386 back end.  I don't think there are 
>> any existing GCC ports for which the 32-bit and 64-bit instruction sets 
>> use different ports, and I think PA is the only one with 32-bit and 64-bit 
>> variants but without -m32/-m64 options to choose between them (instead 
>> requiring separate compilers for the two modes) - and that is probably 
>> because 64-bit PA GNU/Linux hasn't got very far, while HP-UX uses 
>> different object formats for 32-bit and 64-bit which makes a unified 
>> 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.

> 
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]