Topics

Mask Register Value Mapping


CDS
 

From 0.9 stable spec, 5.3.1, table (no number), vector masking is referred to as having LSB. This suggests, yet does not require, that the mask field for each element is greater than bit-size 1.

From same spec, 4.6.1, each element mask bit is given an explicit location, as a single bit.

And yet, for individual operations, the LSB reference is still intact - such as in section 12.4 (Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions).

This suggests some reformatting may be necessary regardless of the correct interpretation:
- If the single-bit-is-always-correct interpretation is to be asserted clearly, it would make sense to remove all of the ".LSB" references when discussing mask input/output fields.
- Otherwise, section 4.6.1 would need to be overhauled to be consistent with the idea of mask entries being multi-bit-per-element.

Thoughts?


Andrew Waterman
 

It is the case that mask elements are always one bit wide in this version of the spec. Removing the “.LSB” holdovers will improve clarity.

On Tue, Sep 22, 2020 at 12:25 PM CDS <cohen.steed@...> wrote:

From 0.9 stable spec, 5.3.1, table (no number), vector masking is referred to as having LSB. This suggests, yet does not require, that the mask field for each element is greater than bit-size 1.



From same spec, 4.6.1, each element mask bit is given an explicit location, as a single bit.



And yet, for individual operations, the LSB reference is still intact - such as in section 12.4 (Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions).

This suggests some reformatting may be necessary regardless of the correct interpretation:
- If the single-bit-is-always-correct interpretation is to be asserted clearly, it would make sense to remove all of the ".LSB" references when discussing mask input/output fields.
- Otherwise, section 4.6.1 would need to be overhauled to be consistent with the idea of mask entries being multi-bit-per-element.

Thoughts?












Nick Knight
 

Hi Cohen,

I think the "LSB references" are carryovers from pre-0.9 versions, when MLEN > 1 was possible.

I can put together a PR to fix this later tonight, unless someone else gets to it sooner.

Best,
Nick Knight


On Tue, Sep 22, 2020 at 12:25 PM CDS <cohen.steed@...> wrote:

From 0.9 stable spec, 5.3.1, table (no number), vector masking is referred to as having LSB. This suggests, yet does not require, that the mask field for each element is greater than bit-size 1.

From same spec, 4.6.1, each element mask bit is given an explicit location, as a single bit.

And yet, for individual operations, the LSB reference is still intact - such as in section 12.4 (Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions).

This suggests some reformatting may be necessary regardless of the correct interpretation:
- If the single-bit-is-always-correct interpretation is to be asserted clearly, it would make sense to remove all of the ".LSB" references when discussing mask input/output fields.
- Otherwise, section 4.6.1 would need to be overhauled to be consistent with the idea of mask entries being multi-bit-per-element.

Thoughts?


CDS
 

Thank you Andrew and Nick.

To avoid having to repeat this question later, is it the intent moving forward (beyond "this version of the spec" being 0.9 stable) that this will hold true in the same format - at least, as of today?


Nick Knight
 

I believe so: I am not aware of any proposals to reintroduce MLEN.

On Tue, Sep 22, 2020 at 12:34 PM CDS <cohen.steed@...> wrote:
Thank you Andrew and Nick.

To avoid having to repeat this question later, is it the intent moving forward (beyond "this version of the spec" being 0.9 stable) that this will hold true in the same format - at least, as of today?


CDS
 

Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.

This would create a phrase

vs2[i] + vs1[i] + v0[i]

which can easily be misleading to the reader - while 'i' has the same value for all three terms, the first two indicate a SEW bit field, whereas the final term indicates a single bit.

Suggestions: include a reminder that v0[i] entries are a single bit under the opening comment in the code block ("Produce sum with carry."); Set a reminder at the bottom of the description section before starting the code text, or indicate a comment on the code line "#Vector-vector-bit".


David Horner
 



On Wed, Sep 23, 2020, 15:10 CDS, <cohen.steed@...> wrote:

Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.

This would create a phrase

vs2[i] + vs1[i] + v0[i]

which can easily be misleading to the reader - while 'i' has the same value for all three terms, the first two indicate a SEW bit field, whereas the final term indicates a single bit.

Suggestions: include a reminder that v0[i] entries are a single bit under the opening comment in the code block ("Produce sum with carry."); Set a reminder at the bottom of the description section before starting the code text, or indicate a comment on the code line "#Vector-vector-bit".


Or my preference a similar annotation that explicitly identifies it as a mast bit:
vs2[i] + vs1[i] + v0[i].m
Or similar.


Andrew Waterman
 



On Wed, Sep 23, 2020 at 2:45 PM David Horner <ds2horner@...> wrote:


On Wed, Sep 23, 2020, 15:10 CDS, <cohen.steed@...> wrote:

Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.

This would create a phrase











vs2[i] + vs1[i] + v0[i]











which can easily be misleading to the reader - while 'i' has the same value for all three terms, the first two indicate a SEW bit field, whereas the final term indicates a single bit.



Suggestions: include a reminder that v0[i] entries are a single bit under the opening comment in the code block ("Produce sum with carry."); Set a reminder at the bottom of the description section before starting the code text, or indicate a comment on the code line "#Vector-vector-bit".


Or my preference a similar annotation that explicitly identifies it as a mast bit:
vs2[i] + vs1[i] + v0[i].m
Or similar.

👍






















Nick Knight
 

The existing draft used the notation v0.mask[i] in dozens of places to denote subscripting of a mask vector (bit granularity). I opted to use the existing notation uniformly, rather than switch to David's proposed v0[i].m . Happy to debate.

The .mask suffix was not previously used in unsubscripted contexts, and I did not introduce it there.

My PR is here: https://github.com/riscv/riscv-v-spec/pull/572 . Let's move further discussion to Github.

Best,
Nick Knight


On Wed, Sep 23, 2020 at 3:11 PM Andrew Waterman <andrew@...> wrote:


On Wed, Sep 23, 2020 at 2:45 PM David Horner <ds2horner@...> wrote:


On Wed, Sep 23, 2020, 15:10 CDS, <cohen.steed@...> wrote:

Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.

This would create a phrase











vs2[i] + vs1[i] + v0[i]











which can easily be misleading to the reader - while 'i' has the same value for all three terms, the first two indicate a SEW bit field, whereas the final term indicates a single bit.



Suggestions: include a reminder that v0[i] entries are a single bit under the opening comment in the code block ("Produce sum with carry."); Set a reminder at the bottom of the description section before starting the code text, or indicate a comment on the code line "#Vector-vector-bit".


Or my preference a similar annotation that explicitly identifies it as a mast bit:
vs2[i] + vs1[i] + v0[i].m
Or similar.

👍






















David Horner
 

You got my thumbs up!

Definitely "something similar" and better that my more cryptic proposal.

Thanks you Cohen for raising  these concerns and Nick for moving this along so quickly.

On 2020-09-24 12:48 a.m., Nick Knight wrote:
The existing draft used the notation v0.mask[i] in dozens of places to denote subscripting of a mask vector (bit granularity). I opted to use the existing notation uniformly, rather than switch to David's proposed v0[i].m . Happy to debate.

The .mask suffix was not previously used in unsubscripted contexts, and I did not introduce it there.

My PR is here: https://github.com/riscv/riscv-v-spec/pull/572 . Let's move further discussion to Github.

Best,
Nick Knight

On Wed, Sep 23, 2020 at 3:11 PM Andrew Waterman <andrew@...> wrote:


On Wed, Sep 23, 2020 at 2:45 PM David Horner <ds2horner@...> wrote:


On Wed, Sep 23, 2020, 15:10 CDS, <cohen.steed@...> wrote:

Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.

This would create a phrase











vs2[i] + vs1[i] + v0[i]











which can easily be misleading to the reader - while 'i' has the same value for all three terms, the first two indicate a SEW bit field, whereas the final term indicates a single bit.



Suggestions: include a reminder that v0[i] entries are a single bit under the opening comment in the code block ("Produce sum with carry."); Set a reminder at the bottom of the description section before starting the code text, or indicate a comment on the code line "#Vector-vector-bit".


Or my preference a similar annotation that explicitly identifies it as a mast bit:
vs2[i] + vs1[i] + v0[i].m
Or similar.

👍