RFR: 8314124: RISC-V: implement Base64 intrinsic - decoding [v4]

Fei Yang fyang at openjdk.org
Mon Aug 26 02:57:04 UTC 2024


On Sun, 25 Aug 2024 22:18:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5517:
>> 
>>> 5515:         __ orr(byte0, byte0, byte1);
>>> 5516:         __ orr(byte0, byte0, byte3);
>>> 5517:         __ slliw(byte2, byte2, 6);
>> 
>> Is this correct to shift left and modify `byte0` - `byte3` before their original value are OR-ed into `combined32Bits`?
>
> I may have misunderstood your question.
> After line 5518, combined32Bits will be byte0[23:18] | byte1[17:12] | byte2[11:6] | byte3[5:0], so before it, we need to move every byte(6 bits) to the right position by shifting except of byte3.

Sorry for being not clear on this. The java code snippet of decodeBlock:

 795                 int b1 = base64[src[sp++] & 0xff];
 796                 int b2 = base64[src[sp++] & 0xff];
 797                 int b3 = base64[src[sp++] & 0xff];
 798                 int b4 = base64[src[sp++] & 0xff];
 799                 if ((b1 | b2 | b3 | b4) < 0) {    // non base64 byte
 800                     return new_dp - dp;
 801                 }
 802                 int bits0 = b1 << 18 | b2 << 12 | b3 << 6 | b4;

L799 simply OR-ed all the initial values of `b1`-`b4` and compare the result with zero. I think this should be reflected on the value of `combined32Bits` when it is used to do following error check. Correspondingly, It should be the OR-ed result of the initial loaded values in `byte0` - `byte3`.

      // error check
      __ bltz(combined32Bits, Exit);


Anything I missed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20026#discussion_r1730591429


More information about the hotspot-dev mailing list