RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Mon Jul 22 11:03:43 PDT 2013
Hi,
I updated the webrev. The code is not without ppc_ and PPC_
prefixes.
http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/
You can have a look at it, and if you have further comments regarding
the style it would be nice to get them early. I still have to adapt all
the remaining changes in the patch queue, and then test it with the
compiler. With that I obviously can run more tests.
I don't really care about the guard. Just tell me what to do...
Best regards,
Goetz.
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Monday, July 22, 2013 6:48 PM
To: Lindenmaier, Goetz
Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote:
>> ??? Or do you propose to change both of them to PPC64?
> Yes, sure, I want to change both.
Why do we need this error if this code is only for PPC64 port? We will have other compilation errors if we try to use
these sources for something else as we found already. Do you have an other usage so you need this guard?
>> All of the existing 64-bit ports have a direct correspondence between
>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64.
>
> I know. And obviously there is a correspondence, as no one will
> Implement an LG64 memory model on a 32 bit machine.
> But the usage intermingles different memory model and architecture:
>
> E.g., the register declaration in register_x86_hpp is fine:
>
> #ifdef AMD64
> CONSTANT_REGISTER_DECLARATION(Register, r8, (8));
>
> But I think this makes no sense (assembler_x86.hpp):
>
> #ifdef _LP64
> void movsbq(Register dst, Address src);
> void movsbq(Register dst, Register src);
> // Move signed 32bit immediate to 64bit extending sign
> void movslq(Address dst, int32_t imm64);
> void movslq(Register dst, int32_t imm64);
>
> and should be guarded by AMD64.
Strictly speaking you are right. But we will never do ilp32 for AMD64 so using _LP64 works for us. Also using AMD64
sometimes rise questions about Intel x64. So using _LP64 is more neutral.
> And I want to get the PPC port right in such matters.
I agree with this since ppc is more flexible than x86, it seems.
> I'm currently removing the ppc_ prefixes ... big fun:)
Sorry about that.
Regards,
Vladimir
> Best regards,
>
> Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Montag, 22. Juli 2013 13:38
> To: Lindenmaier, Goetz
> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
>
> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote:
>
> > 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.
>
> That still doesn't explain why you think LP64 is okay for the atomic
>
> file but you want PPC64 for the orderAccess file. ??? Or do you propose
>
> to change both of them to PPC64?
>
> All of the existing 64-bit ports have a direct correspondence between
>
> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64
>
> is the only 64-bit data model that the OpenJDK sources support.
>
> > 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.
>
> I'm not concerned about compressed oops. No idea where that came from ;-)
>
> David
>
> ------
>
> > 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 <mailto:hotspot-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
> <mailto: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 <mailto:hotspot-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
> <mailto: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.
>
> >>>
>
More information about the hotspot-dev
mailing list