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

[Arnd Bergmann <arnd at arndb dot de>]

On Tuesday 15 November 2011, Joseph S. Myers wrote:
> On Tue, 15 Nov 2011, Arnd Bergmann wrote:

> > > 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.
> 
> So maybe more like SH64 than x86_64, then.

Yes, but it unlike sh64 it would still run as LP64 in Linux initially, though
an ILP32 ABI could be added later.

> If NEON (Advanced SIMD) is similar to 32-bit, perhaps that (being one of 
> the more recent additions to the 32-bit architecture) would be one of the 
> more plausible areas for sharing code (possibly sharing generators like 
> for Tile rather than generated code).

SIMD instructions are integrated into the base instruction set on v7, not
using the coprocessor extensions like neon, which could make the
instruction format too different for this even if the execution units
are shared with NEON.

> (It would be generically desirable to be able to have a single GCC, 
> binutils etc. build supporting multiple targets with a --target= or 
> similar option to select between them, whether or not those targets share 
> a back end in their implementations.  But as I discussed at 
> <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02675.html> that would be a 
> lot of work, whereas wrappers round two separate compiler builds are very 
> simple - so genuinely multi-target compilers become more relevant if you 
> want a single source file to contain functions for different architectures 
> - which adds its own complications, although GDB does support different 
> call frames being on different architectures.)

I've discussed this before with Uli Weigand, and I think it would be
very useful to have a multi-target toolchain support, but if I understand
your proposal correctly, you are thinking of a more fundamental version
that actually has a single cc1 binary with support for multiple targets.

I was hoping that we could fix the -b command line option and add proper
support in the build system to build multiple separate sets of target
binaries with a shared driver, but I now saw that the option has been
removed as of gcc-4.6, presumably for good reasons.

	Arnd