I understand now. I'm on board iff the memory consistency model experts assent.

Sorry, slightly off topic, but what was the rationale for I guess I'm thinking about the possibility of a toolchain relaxing `li, x1, 0; inst x1` into `inst x0`.

Hi Dawei, Unfortunately the V-extension does not currently feature block-matrix multiplication instructions, including the bit-masked versions that you're describing. Some of these operations are inte

Hi Joseph, Thanks for the clarification. The wording in the spec is admittedly vague: "LMUL can have integer values 1,2,4,8.", etc. My understanding of the intent is that all implementations must supp

Sorry, in case it wasn't clear: typo it's not too much of a burden.

Hi Joseph, Thanks for your comments. I apologize, but I don't fully understand your proposal, or the problem it solves. To help explain my confusion, here are two thoughts. The supported LMUL (and EMU

Hi Cohen, I can see the calendar here: https://lists.riscv.org/g/tech-vector-ext/calendar Unfortunately, due to a conflict I can only rarely attend the TG meeting. Best, Nick

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 Dav

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

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,

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

Hi Cohen, Thanks for your careful reading. Hopefully this edit clarifies some of the ambiguity: https://github.com/riscv/riscv-v-spec/pull/565 Best, Nick Knight

Hi Coheen, Thanks for the discussion on the fixed-point vector instructions. Most of Chapter 13 predates my involvement with the Task Group, but I think I am able to address one of your comments: Here

I believe that the (rough) idea I sketched earlier in this thread (May 8) still works with the latest version of the spec --- please correct me if I'm wrong --- what I called "sketchy type-punning" (o

Hi Rich, The reduction operations retain the `.vs` suffix: https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#16-vector-reduction-operations Best, Nick Knight

Hi Bill, My understanding was that the whole register loads and stores work by reinterpreting the (VLEN) bits in a V-register as if SEW were 8; in particular, any bit-permutation induced by vs1r.v wil

Hi Guy, Thanks for your reply. I'll leave a few quick responses, and would like to hear opinions from others on the task group. Agreed. Agreed, especially regarding code storage. When loop strip-minin

I appreciate this discussion about making things friendlier to software. I've always felt the constraints on SLEN-agnostic software to be a nuisance, albeit a mild one. However, I do have a concern ab

Never mind, I misread the git commit log. It appears that no instructions can overwrite the mask register. Sorry.

Hi Krste, It seems that many (all?) masked instructions are now allowed to overwrite the mask register. This new scheme would indeed be simpler --- is this true? Can you give any high-level insight in