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

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 -

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

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

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

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.

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

Yes, but only after it heads into ratification. There are at least two papers. 1) outline the design for people, 2) document the history and development process Krste

count me in Hi team, Do we have a plan to write a V-extension white paper? Is there any interest? I'm thinking along the lines of ARM's SVE paper in IEEE Micro '17. I don't know if this is feasible or

Hi team, Do we have a plan to write a V-extension white paper? Is there any interest? I'm thinking along the lines of ARM's SVE paper in IEEE Micro '17. I don't know if this is feasible or appropriate

Date: 2020/9/18 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~17 Current issues on github: https://github.com/riscv/riscv-v-spec #551 Memory

Krste

Date: 2020/9/4 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~20 Current issues on github: https://github.com/riscv/riscv-v-spec Issues

Date: 2020/8/21 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github: https://github.com/riscv/riscv-v-spec Issues

attached is what we did at convex and it worked quite well. worked well in the context of compiler generated code for stencils and for runtimers like convolution and correlation i am not sure this

I believe I added the correct zoom info on the correct new calendar for tomorrow’s vector task group meeting. Please check and advise if you’re not seeing it, Krste

Ahead of the vector meeting I would like to see if we can address or at least get direction on some of the flagged for pre-v1.0 resolution. There are 3 related flagged issues

i agree with your comment i got this paper from someone who applied their assessment to risc-v vectors http://bsc.es/disclaimer

They mention RISC-V vectors in the intro, but on a quick scan, the results are very ARM-specific, with no real implication for RISC-V vectors. They're pointing out a problem with ARM SVE where

i was made aware of this paper. risc-v vectors are mentioned. one of the key conclusions are (from the abstract) Our experimentsshow that VLA code reaches about 90% of the performance