On Thu, 24 Aug 2023 23:58:35 GMT, Maurizio Cimadamore <mcimadam...@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
