On Fri, 25 Aug 2023 07:48:19 GMT, Martin Doerr <mdo...@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
