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

[Maurizio Cimadamore]

On Fri, 25 Aug 2023 07:48:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

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

Got it - I found these representations:

https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.7.html#BYTEORDER

Very helpful. So you have e.g. a `short` value (loaded from somewhere) and you have to store it on a double-word. Now, if you just stored it at offset 0, you will write the bits 0-15, which are the "most" significant bits in big-endian representation. So, it's backwards. I believe FFM will take care of endianness, so that the bytes 0-7 and 8-15 will be "swapped" when writing into the double-word (right?) but their base offset (0) is still off, as they should really start at offset 48. Hence the shift.

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

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