RFR (M): 8036767 PPC64: Support for little endian execution model

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Tue Mar 18 09:58:08 UTC 2014


> it could be done with PPC64_ENDIANNESS check
Yes, that's fine.  I would further propose to choose a neutral name ENDIANESS
and set it for all architectures.  Platform specific variables should be avoided in 
shared files.  And it's used in ppc64.make, so that should be fine.
Also -DLITTLE_ENDIAN could be set in a shared makefile once for all if there is a 
variable ENDIANESS.

But I don't see how you want to fix the build path with this.  It's used in a lot of
places, in linux/Makefile for setting the subdirs
   SUBDIRS_C1        = $(addprefix $(OSNAME)_$(BUILDARCH)_compiler1/,$(TARGETS))
and also when doing the install.
Further it's used in buildtree.make to set up these directories.

One would have to change all these locations to 
   SUBDIRS_C1        = $(addprefix $(OSNAME)_$(BUILDARCH)$(PPC64_ENDIANESS)_compiler1/,$(TARGETS))

But I don’t want to insist on the setting of a different build path.

Best regards,

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Tuesday, March 18, 2014 2:36 AM
To: Lindenmaier, Goetz; Magnus Ihse Bursie; David Holmes
Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

On 3/17/14 6:36 AM, Lindenmaier, Goetz wrote:
> Hi Magnus,
> The change keeps target cpu and target cpu arch as is.  The C-code uses
> -DLITTLE_ENDIAN to distinguish implementation differences.
> As I understand, we discuss the setting of BUILDARCH in the makefiles.
> Indirectly it is set from uname, which returns ppc64le on these machines.
> This affects the following namings:
>    1. the build path:    linux_ppc64le-compiler2

I am fine with it (your case is reasonable) but it could be done with 
PPC64_ENDIANNESS check for PLATFORM and VM_PLATFORM definition.

>    2. which makefiles used:  platform_ppc64le and ppc64le.make

These causes the main resistance to these changes.

> 1.) would allow to build ppc64 and ppc64le from the same repo without setting ALT_OUTPUTDIR
> 2.) BUILDARCH=ppc64le means two new files, where platform_ppc64 and platform_ppc64le
>        are the same.
>       BUILDARCH=ppc64  means no new files, but lots of platform checks in ppc64.make,
>       which is uncommon.  So far these files are just settings.

It is only one check as Volker showed.

> I don't think setting
>    LIBARCH=ppc64le  ==>  jre/lib/ppc64le/server/libjvm.so

It is questionable. Why you need jre/lib/ppc64le and not the same 
jre/lib/ppc64? It does not make sense to me to deploy JDK which have 
both of them in one jre/lib.


> and the settings in os_linux.cpp are questioned.
> Best regards,
>    Goetz.
> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie
> Sent: Montag, 17. März 2014 12:36
> To: David Holmes
> Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak
> Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model
> On 2014-03-17 05:13, David Holmes wrote:
>> On 15/03/2014 7:11 AM, Alexander Smundak wrote:
>>> Ping.
>> My position hasn't changed. I don't think this needs to be, or should
>> be, a distinct architecture.
>> I've added build-dev to cc list to see what our build experts think.
> I'm not sure I've completely understood the discussion (it has jumped
> around a bit between mailing lists), but I think I agree with David
> here. Architecture is a term that implies general common features, not
> specific differences.
> While hotspot and the rest of the jdk build is not currently in sync
> with this terminology, in the common configure and makefiles we use the
> terminology "target cpu" (which can be for instance "x86_64" or
> "sparcv9" and "target cpu arch" (which can be for instance "x86" or
> "sparc").
> Regarding ppc, we currently define the target cpu arch "ppc" and two
> target cpus, "ppc" and "ppc64".
> Perhaps it would be more approriate to consider this a separate target
> cpu ("ppc64le"), but not a separate target cpu architecture? But that
> would be on the top-level -- I'm not sure how that would map properly to
> the current hotspot build system.
> /Magnus

More information about the hotspot-dev mailing list