RFR: 8314124: RISC-V: implement Base64 intrinsic - decoding [v4]
Hamlin Li
mli at openjdk.org
Mon Aug 26 16:49:05 UTC 2024
On Mon, 26 Aug 2024 02:54:24 GMT, Fei Yang <fyang at openjdk.org> wrote:
>> 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 not being 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?
`(b1 | b2 | b3 | b4) < 0`, this java code is to tell if any of b1-b4 is < 0.
On the other side, `bltz(combined32Bits, Exit)` is doing the similar thing (same effect, but different way), as when loading byte1-4, `lb` will sign-extend it, if any of byte1-4 < 0, then the top bit will be 1, and after shift left, top bit will still be 1, so as a result, we can use combined32Bits to tell if any of byte1-4 < 0, and at the same time, we can use combined32Bits to decode the final data (from 4 bytes to 3 bytes).
Hope this answers your question?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20026#discussion_r1731515640
More information about the hotspot-dev
mailing list