Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz wrote: >> Jie Fu has updated the pull request with a new target base due to a merge or >> a rebase. The incremental webrev excludes the unrelated changes brought in >> by the merge/rebase. The pull request contains six additional commits since >> the last revision: >> >> - Address review comments >> - Merge branch 'master' into JDK-8284992 >> - Merge branch 'master' into JDK-8284992 >> - Address review comments >> - Merge branch 'master' into JDK-8284992 >> - 8284992: Fix misleading Vector API doc for LSHR operator > > It should be possible for you finalize now. Thanks @PaulSandoz for the review and help. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v4]
On Fri, 29 Apr 2022 06:35:44 GMT, Jie Fu wrote: >> Hi all, >> >> The Current Vector API doc for `LSHR` is >> >> Produce a>>>(n&(ESIZE*8-1)). Integral only. >> >> >> This is misleading which may lead to bugs for Java developers. >> This is because for negative byte/short elements, the results computed by >> `LSHR` will be different from that of `>>>`. >> For more details, please see >> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . >> >> After the patch, the doc for `LSHR` is >> >> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral >> only. >> >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or > a rebase. The incremental webrev excludes the unrelated changes brought in by > the merge/rebase. The pull request contains eight additional commits since > the last revision: > > - Address CSR review comments > - Merge branch 'master' into JDK-8284992 > - Address review comments > - Merge branch 'master' into JDK-8284992 > - Merge branch 'master' into JDK-8284992 > - Address review comments > - Merge branch 'master' into JDK-8284992 > - 8284992: Fix misleading Vector API doc for LSHR operator Marked as reviewed by psandoz (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v4]
> Hi all, > > The Current Vector API doc for `LSHR` is > > Produce a>>>(n&(ESIZE*8-1)). Integral only. > > > This is misleading which may lead to bugs for Java developers. > This is because for negative byte/short elements, the results computed by > `LSHR` will be different from that of `>>>`. > For more details, please see > https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . > > After the patch, the doc for `LSHR` is > > Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only. > > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Address CSR review comments - Merge branch 'master' into JDK-8284992 - Address review comments - Merge branch 'master' into JDK-8284992 - Merge branch 'master' into JDK-8284992 - Address review comments - Merge branch 'master' into JDK-8284992 - 8284992: Fix misleading Vector API doc for LSHR operator - Changes: - all: https://git.openjdk.java.net/jdk/pull/8291/files - new: https://git.openjdk.java.net/jdk/pull/8291/files/7e82e721..0161571b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=02-03 Stats: 6657 lines in 233 files changed: 5591 ins; 490 del; 576 mod Patch: https://git.openjdk.java.net/jdk/pull/8291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291 PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz wrote: >> Jie Fu has updated the pull request with a new target base due to a merge or >> a rebase. The incremental webrev excludes the unrelated changes brought in >> by the merge/rebase. The pull request contains six additional commits since >> the last revision: >> >> - Address review comments >> - Merge branch 'master' into JDK-8284992 >> - Merge branch 'master' into JDK-8284992 >> - Address review comments >> - Merge branch 'master' into JDK-8284992 >> - 8284992: Fix misleading Vector API doc for LSHR operator > > It should be possible for you finalize now. Hi @PaulSandoz , the CSR had been approved and I pushed one more commit to address the CSR review comments. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz wrote: > It should be possible for you finalize now. Done. Thanks @PaulSandoz . - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu wrote: >> Hi all, >> >> The Current Vector API doc for `LSHR` is >> >> Produce a>>>(n&(ESIZE*8-1)). Integral only. >> >> >> This is misleading which may lead to bugs for Java developers. >> This is because for negative byte/short elements, the results computed by >> `LSHR` will be different from that of `>>>`. >> For more details, please see >> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . >> >> After the patch, the doc for `LSHR` is >> >> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral >> only. >> >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or > a rebase. The incremental webrev excludes the unrelated changes brought in by > the merge/rebase. The pull request contains six additional commits since the > last revision: > > - Address review comments > - Merge branch 'master' into JDK-8284992 > - Merge branch 'master' into JDK-8284992 > - Address review comments > - Merge branch 'master' into JDK-8284992 > - 8284992: Fix misleading Vector API doc for LSHR operator It should be possible for you finalize now. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Thu, 28 Apr 2022 00:08:41 GMT, Paul Sandoz wrote: > I created one, filled it in, and assigned it to you (for other examples you > can search in the issue tracker, this one quite is simple so i thought it was > quicker to do myself to show you). For any specification change we need to > review and track that change (independent of any implementation changes, if > any). > > If you are ok with it I can add myself as reviewer, then you can "Finalize" > it (see button on same line as "Edit"), triggering a review request, from > which we may receive comments to address, and once addressed and final, it > will unblock the PR for integration. Thanks @PaulSandoz for your help. Yes, I think it's good enough. I made a small change which just adding a `(`. https://user-images.githubusercontent.com/19923746/165657177-f44f7f7d-44da-4921-a98c-5f6b9a3d9e36.png";> Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu wrote: >> Hi all, >> >> The Current Vector API doc for `LSHR` is >> >> Produce a>>>(n&(ESIZE*8-1)). Integral only. >> >> >> This is misleading which may lead to bugs for Java developers. >> This is because for negative byte/short elements, the results computed by >> `LSHR` will be different from that of `>>>`. >> For more details, please see >> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . >> >> After the patch, the doc for `LSHR` is >> >> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral >> only. >> >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or > a rebase. The incremental webrev excludes the unrelated changes brought in by > the merge/rebase. The pull request contains six additional commits since the > last revision: > > - Address review comments > - Merge branch 'master' into JDK-8284992 > - Merge branch 'master' into JDK-8284992 > - Address review comments > - Merge branch 'master' into JDK-8284992 > - 8284992: Fix misleading Vector API doc for LSHR operator I created one, filled it in, and assigned it to you (for other examples you can search in the issue tracker, this one quite is simple so i thought it was quicker to do myself to show you). For any specification change we need to review and track that change (independent of any implementation changes, if any). If you are ok with it I can add myself as reviewer, then you can "Finalize" it (see button on same line as "Edit"), triggering a review request, from which we may receive comments to address, and once addressed and final, it will unblock the PR for integration. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Wed, 27 Apr 2022 17:17:55 GMT, Paul Sandoz wrote: > Thanks, looks good, we will need to create a CSR. Have you done that before? No, and I don't know much about a CSR. Is there any example for a doc fix CSR to follow? Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu wrote: >> Hi all, >> >> The Current Vector API doc for `LSHR` is >> >> Produce a>>>(n&(ESIZE*8-1)). Integral only. >> >> >> This is misleading which may lead to bugs for Java developers. >> This is because for negative byte/short elements, the results computed by >> `LSHR` will be different from that of `>>>`. >> For more details, please see >> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . >> >> After the patch, the doc for `LSHR` is >> >> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral >> only. >> >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or > a rebase. The incremental webrev excludes the unrelated changes brought in by > the merge/rebase. The pull request contains six additional commits since the > last revision: > > - Address review comments > - Merge branch 'master' into JDK-8284992 > - Merge branch 'master' into JDK-8284992 > - Address review comments > - Merge branch 'master' into JDK-8284992 > - 8284992: Fix misleading Vector API doc for LSHR operator Thanks, looks good, we will need to create a CSR. Have you done that before? - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
> Hi all, > > The Current Vector API doc for `LSHR` is > > Produce a>>>(n&(ESIZE*8-1)). Integral only. > > > This is misleading which may lead to bugs for Java developers. > This is because for negative byte/short elements, the results computed by > `LSHR` will be different from that of `>>>`. > For more details, please see > https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . > > After the patch, the doc for `LSHR` is > > Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only. > > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Address review comments - Merge branch 'master' into JDK-8284992 - Merge branch 'master' into JDK-8284992 - Address review comments - Merge branch 'master' into JDK-8284992 - 8284992: Fix misleading Vector API doc for LSHR operator - Changes: - all: https://git.openjdk.java.net/jdk/pull/8291/files - new: https://git.openjdk.java.net/jdk/pull/8291/files/1c7f4584..7e82e721 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=01-02 Stats: 8171 lines in 245 files changed: 5201 ins; 1132 del; 1838 mod Patch: https://git.openjdk.java.net/jdk/pull/8291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291 PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
On Tue, 26 Apr 2022 21:41:37 GMT, Paul Sandoz wrote:
> After talking with John here's what we think is a better approach than what I
> originally had in mind:
>
> 1. In the class doc of `VectorOperators` add a definition for `EMASK`
> occurring after the definition for `ESIZE`:
>
> ```
> * {@code EMASK} — the bit mask of the operand type, where {@code
> EMASK=(1< ```
>
> 2. Change `LSHR` to be:
>
> ```
> /** Produce {@code (a&EMASK)>>>(n&(ESIZE*8-1))}. Integral only. */
> ```
>
> That more clearly gets across operating in the correct domain for sub-word
> operand types, which was the original intention (e.g. the right shift value).
Good suggestion!
This makes sense to me.
Updated.
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
On Thu, 21 Apr 2022 04:23:22 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by
>> `LSHR` will be different from that of `>>>`.
>> For more details, please see
>> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>>
>> After the patch, the doc for `LSHR` is
>>
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral
>> only.
>>
>>
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or
> a rebase. The incremental webrev excludes the unrelated changes brought in by
> the merge/rebase. The pull request contains three additional commits since
> the last revision:
>
> - Address review comments
> - Merge branch 'master' into JDK-8284992
> - 8284992: Fix misleading Vector API doc for LSHR operator
After talking with John here's what we think is a better approach than what I
originally had in mind:
1. In the class doc of `VectorOperators` add a definition for `EMASK` occurring
after the definition for `ESIZE`:
* {@code EMASK} — the bit mask of the operand type, where {@code
EMASK=(1<>>(n&(ESIZE*8-1))}. Integral only. */
That more clearly gets across operating in the correct domain for sub-word
operand types, which was the original intention (e.g. the right shift value).
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by
>> `LSHR` will be different from that of `>>>`.
>> For more details, please see
>> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>>
>> After the patch, the doc for `LSHR` is
>>
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral
>> only.
>>
>>
>> Thanks.
>> Best regards,
>> Jie
>
> We can raise attention to that:
>
> /** Produce {@code a>>>(n&(ESIZE*8-1))}
> * (The operand and result are converted if the operand type is {@code byte}
> or {@code short}, see below). Integral only.
> * ...
> */
Hi @PaulSandoz ,
I add a piece of notice at the end of the brief description of `LSHR` since not
everyone would click and see the details without the change.
What do you think?
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz wrote:
> We can raise attention to that:
>
> ```
> /** Produce {@code a>>>(n&(ESIZE*8-1))}
> * (The operand and result are converted if the operand type is {@code byte}
> or {@code short}, see below). Integral only.
> * ...
> */
> ```
It seems still misleading if we don't change the brief description of `LSHR`.
How about adding 'see details for attention' like this?
https://user-images.githubusercontent.com/19923746/164371693-6e26842c-47f4-44f5-8371-1906ae8e6218.png";>
And the patch had been updated.
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
> Hi all, > > The Current Vector API doc for `LSHR` is > > Produce a>>>(n&(ESIZE*8-1)). Integral only. > > > This is misleading which may lead to bugs for Java developers. > This is because for negative byte/short elements, the results computed by > `LSHR` will be different from that of `>>>`. > For more details, please see > https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . > > After the patch, the doc for `LSHR` is > > Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only. > > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Address review comments - Merge branch 'master' into JDK-8284992 - 8284992: Fix misleading Vector API doc for LSHR operator - Changes: - all: https://git.openjdk.java.net/jdk/pull/8291/files - new: https://git.openjdk.java.net/jdk/pull/8291/files/50235163..1c7f4584 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=00-01 Stats: 11427 lines in 826 files changed: 6952 ins; 1816 del; 2659 mod Patch: https://git.openjdk.java.net/jdk/pull/8291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291 PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote: > Hi all, > > The Current Vector API doc for `LSHR` is > > Produce a>>>(n&(ESIZE*8-1)). Integral only. > > > This is misleading which may lead to bugs for Java developers. > This is because for negative byte/short elements, the results computed by > `LSHR` will be different from that of `>>>`. > For more details, please see > https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . > > After the patch, the doc for `LSHR` is > > Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only. > > > Thanks. > Best regards, > Jie Add hotspot-compiler since the JBS has been moved there. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by
> `LSHR` will be different from that of `>>>`.
> For more details, please see
> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>
> After the patch, the doc for `LSHR` is
>
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>
>
> Thanks.
> Best regards,
> Jie
We can raise attention to that:
/** Produce {@code a>>>(n&(ESIZE*8-1))}
* (The operand and result are converted if the operand type is {@code byte}
or {@code short}, see below). Integral only.
* ...
*/
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Wed, 20 Apr 2022 00:46:32 GMT, Paul Sandoz wrote:
> The intended pattern for the operator tokens is to present a short symbolic
> description using Java operators and common methods. It would be good to try
> and keep with this pattern, and clarify for the extra cases. Here's what i
> had in mind:
>
> ```
> /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only.
> *
> * For operand types {@code byte} and {@code short} the operation behaves as
> if the operand is first implicitly widened
> * to an {@code int} value with {@code (a & ((1 << ESIZE) - 1))} the result
> of which is then applied as the operand to this
> * operation, the result of the operation is then narrowed from {@code int}
> to the operand type using an explicit cast.
> */
> public static final /*bitwise*/ Binary LSHR;
> ```
This works only if people would like to read the detailed description of `LSHR`
carefully.
Actually, most developers would still see the brief description first.
https://user-images.githubusercontent.com/19923746/164127620-90a73d29-868e-46d8-9562-2c5b2021f13b.png";>
If they don't click out the detailed description further or don't read it
carefully, it's still misleading.
Maybe, we'd better not to use `>>>` in the brief description since `LSHR`
behaves differently with the common used `>>>`.
What do you think?
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by
> `LSHR` will be different from that of `>>>`.
> For more details, please see
> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>
> After the patch, the doc for `LSHR` is
>
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>
>
> Thanks.
> Best regards,
> Jie
The intended pattern for the operator tokens is to present a short symbolic
description using Java operators and common methods. It would be good to try
and keep with this pattern, and clarify for the extra cases. Here's what i had
in mind:
/** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only.
*
* For operand types {@code byte} and {@code short} the operation behaves
as if the operand is first implicitly widened
* to an {@code int} value with {@code (a & ((1 << ESIZE) - 1))} the
result of which is then applied as the operand to this
* operation, the result of the operation is then narrowed from {@code
int} to the operand type using an explicit cast.
*/
public static final /*bitwise*/ Binary LSHR;
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Tue, 19 Apr 2022 16:11:37 GMT, Paul Sandoz wrote: > I need to think a little more about this. The specification is not accurate > and likely requires a CSR. > > My initial thoughts are I would prefer the operation to retain reference to > the succinct definition using the logical right shift operator but we add > additional specification explaining the cases for `byte` and `short`, namely > that the result is widened to an `int` as if by `(a & ((1 << ESIZE) - 1))` > and the result narrowed. That's commonly (at least for the widening part) how > `>>>` is used with `byte` and `short`, and i think would be clearer to be > explicit in that regard. OK. To avoid confusing I would prefer using the description of `>>>` in the new vector operator, which would perform the same behavior as the scalar `>>>`. - PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote: > Hi all, > > The Current Vector API doc for `LSHR` is > > Produce a>>>(n&(ESIZE*8-1)). Integral only. > > > This is misleading which may lead to bugs for Java developers. > This is because for negative byte/short elements, the results computed by > `LSHR` will be different from that of `>>>`. > For more details, please see > https://github.com/openjdk/jdk/pull/8276#issue-1206391831 . > > After the patch, the doc for `LSHR` is > > Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only. > > > Thanks. > Best regards, > Jie I need to think a little more about this. The specification is not accurate and likely requires a CSR. My initial thoughts are I would prefer the operation to retain reference to the succinct definition using the logical right shift operator but we add additional specification explaining the cases for `byte` and `short`, namely that the result is widened to an `int` as if by `(a & ((1 << ESIZE) - 1))` and the result narrowed. That's commonly (at least for the widening part) how `>>>` is used with `byte` and `short`, and i think would be clearer to be explicit in that regard. - PR: https://git.openjdk.java.net/jdk/pull/8291
