On Fri, 25 Aug 2023 09:24:15 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> 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. After looking for a while, I think having the new binding operator is needed. e.g. for stores: we load a 32 bit value from the end of a struct, then the low-order bits of the value needs to be padded with zeros to get a 64 bit register value, leaving the original 32 bit value in the high order bits. This can't be handled by the current cast operator. e.g. if we had an int -> long cast conversion, then in the resulting value the low-order bits would be occupied by the 32 bit value, which is incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314524955
