RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.

[Lindenmaier, Goetz]

Hi David,

PPC64: describes an instruction set / machine with all it's specialities.  And the instruction set
	we implemented the port for has an atomic 64-bit instruction.
LP64 describes a memory model.  I.E, long == 64bit, int == 32bit , pointer == 64 bit.
In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the 
PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then
you would have an atomic 64-bit instruction.

Compressed oops make sense to protect with LP64, because they are only helpful
with 64 bit pointers.  While usage of LP64 is not exactly correct here, ILP64, SLP64 
etc would also use compressed oops.  But it's close enough I guess.

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Montag, 22. Juli 2013 05:27
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov
Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.

On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
>> I think orderAccess_linux_ppc.inline.hpp should have:
>>     34 #ifndef _LP64
>>     35 #error "Atomic currently only impleneted for PPC64"
>>     36 #endif
> You're right, I'll fix this.
> If you don't object I'll guard it by PPC64 as it depends on the
> processor architecture and not the memory model.

Is there some case where _LP64 would be true but PPC64 would not be ??? 
They seem effectively interchangeable but I don't know why you would use 
one in one file and the other in another file ??

Thanks,
David

> If I will change the ppc_ prefixes that'll take a bit, especially
> as I will have to adapt all the alignments :(.
> But that does not matter, as we need to wait for your build
> change anyways.
>
> Best regards,
>    Goetz.
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Friday, July 19, 2013 7:29 AM
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov
> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
>
> Hi Goetz,
>
> Only a brief glance through ...
>
> I think orderAccess_linux_ppc.inline.hpp should have:
>
>     34 #ifndef _LP64
>     35 #error "Atomic currently only impleneted for PPC64"
>     36 #endif
>
> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only
> be atomic on ppc64).
>
> BTW typo: 35 #error "Atomic currently only impleneted for PPC64"
>
> I also find the ppc_ prefix used in the assembly code somewhat redundant.
>
> David
> -----
>
> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> This time with webrev. Sorry for the double mails.
>>
>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for
>> the PPC64 interpreter port on linux.
>>
>> With this change you can do a core build on ppc64 and run the VM interpreter only.
>> It executes simple programs as jvm98.
>> The change requires
>>
>> *         8016697: Use stubs to implement safefetch
>>
>> *         8020059: The flag introduced by 8014972 is not defined ...
>> which will arrive soon in the staging repository.
>>
>> I marked the change as XL as it contains a lot of code.  Nevertheless the
>> code has no impact on the existing Oracle platforms.
>>
>> The change touches a single shared file, globals.hpp, removing a
>> special case introduced for the port.  This is because we
>> integrated some changes earlier than originally intended.
>>
>> Please review the change.  Does it need testing on Oracle side?
>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/
>>
>> Best regards,
>>     Goetz.
>>