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

[Arnd Bergmann <arnd at arndb dot de>]

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?

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.

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

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

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

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

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

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.

	Arnd