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

["Joseph S. Myers" <joseph at codesourcery dot com>]

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?

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.

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

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

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

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

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.

(Hybrid approaches include x86_64, with its own glibc port separate from 
i386 but with all the installed headers supporting both 32-bit and 64-bit 
modes and with the ports in others components shared.)

-- 
Joseph S. Myers
joseph@codesourcery.com