RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API
Maurizio Cimadamore
mcimadamore at openjdk.org
Fri Aug 25 00:01:10 UTC 2023
On Thu, 24 Aug 2023 23:55:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695:
>>
>>> 693: * Negative [shiftAmount] shifts right and converts to int if needed.
>>> 694: */
>>> 695: record ShiftLeft(int shiftAmount, Class<?> type) implements Binding {
>>
>> Given the situation you are facing, perhaps adding the new binding here is unavoidable. Let's wait to hear from @JornVernee. In the meantime, can you point me to a document which explains this behavior? I'm curious and I'd like to know more :-)
>
> Maybe I'm starting to see it - it's not a special rule, as much as it is a consequence of the endianness. E.g. if you have a struct that is 64 + 32 bytes, you can store the first 64 bytes as a long. Then, there's an issue as we have to fill another long, but we have only 32 bits of value. Is it the problem that if we just copy the value into the long word "as is" it will be stored in the "wrong" 32 bits? So the shift takes care of that, I guess?
If my assumption above is correct, then maybe another way to solve the problem, would be to, instead of adding a new shift binding, to generalize the VM store binding we have to allow writing a smaller value into a bigger storage, with an offset. Correct?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304982593
More information about the hotspot-compiler-dev
mailing list