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