RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API

[Martin Doerr]

On Thu, 24 Aug 2023 23:58:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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?

The ABI says: "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." [https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#PARAM-PASS].
I have written examples which pass 9 and 15 Bytes.
In the first case, we need to get 0x0001020304050607 in the first argument and 0x08XXXXXXXXXXXXXX into the second argument (X is "don't care"). Shift amount is 7.
In the second case, we need to get 0x0001020304050607 in the first argument and 0x08090a0b0c0d0eXX into the second argument. Shift amount is 1.
In other words, we need shift amounts between 1 and 7. Stack slots and registers are always 64 bit on PPC64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305313810