From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: libc-ports@sourceware.org
Subject: Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc
Date: Mon, 14 Nov 2011 23:38:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1111142308540.23528@digraph.polyomino.org.uk> (raw)
In-Reply-To: <201111142216.54543.arnd@arndb.de>
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
next prev parent reply other threads:[~2011-11-14 23:38 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 0:55 Chris Metcalf
2011-11-10 0:58 ` [PATCH v2 2/10] " Chris Metcalf
2011-11-15 0:32 ` Joseph S. Myers
2011-11-10 4:14 ` [PATCH v2 0/10] " Mike Frysinger
2011-11-10 4:27 ` Chris Metcalf
2011-11-11 18:10 ` Roland McGrath
2011-11-11 18:35 ` Carlos O'Donell
2011-11-11 19:07 ` Roland McGrath
2011-11-11 19:22 ` Carlos O'Donell
2011-11-10 4:36 ` [PATCH v2 1a/10] sysdeps/tile support Chris Metcalf
2011-11-15 0:00 ` Joseph S. Myers
2011-11-15 15:54 ` Joseph S. Myers
2011-11-15 18:14 ` Chris Metcalf
2011-11-20 17:06 ` Joseph S. Myers
2011-11-20 17:34 ` Chris Metcalf
2011-11-20 17:48 ` Joseph S. Myers
2011-11-21 14:14 ` Carlos O'Donell
2011-11-21 14:41 ` Chris Metcalf
2011-12-04 0:02 ` Chris Metcalf
2011-12-04 0:28 ` Chris Metcalf
2011-12-04 1:17 ` Joseph S. Myers
2011-12-04 4:13 ` Christopher Faylor
2011-12-04 9:35 ` Andreas Schwab
2011-12-04 0:47 ` Chris Metcalf
2011-12-04 1:17 ` Joseph S. Myers
[not found] ` <201111100435.pAA4ZuEh008673@farm-0002.internal.tilera.com>
2011-11-10 5:21 ` [PATCH v2 1b/10] sysdeps/unix/sysv/linux/tile support Chris Metcalf
2011-11-15 0:06 ` Joseph S. Myers
2011-11-15 3:32 ` Chris Metcalf
2011-11-11 17:48 ` [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc Ulrich Drepper
2011-11-11 21:02 ` Mike Frysinger
2011-11-11 21:33 ` Chris Metcalf
2011-11-11 21:42 ` Roland McGrath
2011-11-12 2:43 ` Arnd Bergmann
2011-11-12 3:16 ` Roland McGrath
2011-11-12 15:05 ` Joseph S. Myers
2011-11-14 22:17 ` Arnd Bergmann
2011-11-14 23:38 ` Joseph S. Myers [this message]
2011-11-15 5:38 ` Arnd Bergmann
2011-11-15 16:15 ` Joseph S. Myers
2011-11-15 17:43 ` Richard Earnshaw
2011-11-15 17:50 ` Joseph S. Myers
2011-11-15 17:46 ` Arnd Bergmann
2011-11-15 18:05 ` Joseph S. Myers
2011-11-15 17:21 ` Richard Earnshaw
2011-11-15 17:45 ` Joseph S. Myers
2011-11-15 17:50 ` Richard Earnshaw
2011-11-11 21:58 ` Chris Metcalf
2011-11-11 22:15 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1111142308540.23528@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=arnd@arndb.de \
--cc=libc-ports@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).