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

David Holmes david.holmes at oracle.com
Mon Mar 17 04:13:35 UTC 2014

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.


> On Wed, Mar 12, 2014 at 4:59 PM, Alexander Smundak <asmundak at google.com> wrote:
>> I was concerned by the term 'variant', which might suggest that the applications
>> built for PPC64 and PPC64LE are binary compatible. They are not.
>> On Wed, Mar 12, 2014 at 3:55 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> On 12/03/2014 9:19 AM, Alexander Smundak wrote:
>>>> On Tue, Mar 11, 2014 at 3:51 PM, Vladimir Kozlov
>>>> <vladimir.kozlov at oracle.com> wrote:
>>>>> It would only help if you could do cross compilation to have both build
>>>>> variants at the same place. Currently you can only build le variant on
>>>>> ppc64le machine and vice versa. That is why, I think, David asked if we
>>>>> can
>>>>> control what variant to build.
>>>> Just to clarify the situation a bit: ppc64le is not a variant of ppc64.
>>>> That is,
>>>> an application compiled for the little-endian PowerPC64 does not "just
>>>> run" on
>>>> the big-endian PowerPC64 (albeit OS can have such feature, similar to the
>>>> ability of the Linux running on x86_64 CPU to run 32-bit x86
>>>> applications).
>>>> So ppc64le is a different architecture from ppc64.
>>> I disagree with that classification for "architecture" and it seems at odds
>>> with the literature which describes the endian-ness selection as a "mode".
>>> David
>>> -----
>>>>> I would like to see the changes based on Volker suggestion. We can
>>>>> compare
>>>>> them and decide which way to go.
>>>> Volker has the detailed suggestion here:
>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html
>>>> and it involves additional Make variable and if statements in the
>>>> platform makefile
>>>>    where they are not supposed to be present.

More information about the hotspot-dev mailing list