This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc
On Tue, 15 Nov 2011, Arnd Bergmann wrote:
> > 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.
All new GCC ports do seem to end up being reviewed by me and Richard
Henderson....
> 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.
Heavy limits to what's conditional actually remind me rather of Thumb-1.
Though with Thumb-1 you can and do move between ARM mode and Thumb mode at
runtime (and in principle attributes to compile some functions as ARM and
others as Thumb would make sense) which is not something that makes so
much sense for 32-bit and 64-bit modes.
> > 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.
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).
(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.)
--
Joseph S. Myers
joseph@codesourcery.com