Hi, > 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, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.koz...@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. Thanks, Vladimir > 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-boun...@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 >
