[aarch64-port-dev ] VAR_CPU_ARCH for ARM platforms
gnu.andrew at redhat.com
Thu Jan 28 21:07:39 UTC 2016
----- Original Message -----
> Hi guys,
> And indeed, please don't forget about AArch32 port. It's like ARM but it's
> quite different, you know. And it is currently using aarch32 value as
> VAR_CPU and VAR_CPU_ARCH
> On Wed, Dec 23, 2015 at 7:56 PM Andrew Haley <aph at redhat.com> wrote:
> > On 23/12/15 14:55, Bob Vandette wrote:
> > > In my push to the mobile/dev forest, I changed VAR_CPU_ARCH on arm
> > > platforms to always use arm for both 32 and 64 bit arm builds to be
> > > consistent with the setting for x86/x86_64.
> > This isn't a similar situation, IMO.
> > > http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ <
> > http://cr.openjdk.java.net/~bobv/8145936/webrev.00/>
> > >
> > > My assumption which is confirmed by most of the usage in the
> > > makefiles is that VAR_CPU_ARCH should be set to the generic ARCH
> > > family (x86, arm) for both 32 and 64 bit builds.
> > >
> > > My motivation for doing this was initially for the selection of the
> > > Socket and UnixConstant template files used in cross compilation
> > > since these files contain the same content for arm and aarch64.
> > I'm not convinced this makes any sense. The only thing the ARM
> > architectures have in common is that they come from the same company.
> > This is not true of x86_64, which is a rather elaborate 64-bit
> > extension of x86. For examples of how the ARM/AArch64 split is
> > handled elsewhere, note that the Linux kernel, GCC, and GNU binutils
> > arches are all separate.
> > > There are a lot of hacks in both open and closed makefiles to set
> > > various variable based on ARCH in order to end up with the correct
> > > variables.
> > >
> > > In hotspot/make/defs.make, we undo the VAR_CPU_ARCH setting of x86
> > > for x86_64 builds by checking for LP64! This is not done for arm.
> > It really should not need to be. AArch64 is not ARM.
> > Andrew.
I just came across this mail when looking through AArch32 mails, and I
hope the change has now been reversed. It seems quite odd to be making
such a change in the mobile/dev forest rather than proposing it to the
AArch64 & AArch32 projects.
As Andrew points out, the history of arm/AArch64 is quite different to that
of x86/x86_64. Historically, x86_64 was introduced as a way to provide a
64-bit variant of x86, while maintaining compatibility with decades of
existing 32-bit binaries. It was introduced by AMD and is done in such a
way that a x86_64 chip is essentially an x86 chip when not operating in
LONG mode. Intel had already tried to do 64-bit with a complete redesign
in the form of the Itanium and one of its failings was the slow emulation
of 32-bit code. x86 has a long legacy of 32-bit binaries, many of which
are proprietary and simply can't be ported to 64-bit.
This scenario makes it fairly unique and other architectures handle the
32/64-bit split differently. For example, I believe 64-bit has always
been part of the design for PowerPC and SPARC, and its use doesn't share
the performance advantages of x86 over x86_64, because it doesn't use
the switch to 64-bit to add a bunch of other features, such as doubling
register provision, that were missing from the original architecture. It
is really just a case of working with a larger bit-size.
Anyway, the reason for me entering into this conversation is to point out
that we've already been burnt by a similar attempt at cleanup. When ppc64le
was merged, it was decided that it could just be referred to as 'ppc64'.
In actual use, this turned out to be a problem because tools running on the
platform couldn't work out whether they were on ppc64[be] or ppc64le and use
appropriate native binaries. I, along with others working on the PPC port,
have spent a lot of time diagnosing and fixing this over the past year.
I'd prefer that we didn't make the same mistake with arm and AArch64.
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
More information about the hotspot-runtime-dev