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

[Hamlin Li]

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