[aarch64-port-dev ] VAR_CPU_ARCH for ARM platforms

[Andrew Hughes]

----- 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
> 
> Thanks,
> Andrey
> 
> 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.

Thanks,
-- 
Andrew :)

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