Almost all vector instructions already have to check their vector operands to make sure the register numbers are compatible with (dynamic) LMUL. This is further complicated in, e.g., the case of mixed

https://godbolt.org/z/qj6WzYc76

V-extension version 1.0 hasn't been frozen yet. Its second release candidate was posted just yesterday: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0-rc2 I wouldn't expect toolchain support

Hi Tony, All of the vector permutation instructions can be simulated using the memory system. For example, vslide can be simulated by storing the vector register and loading it at an offset; vrgather

I guess the publicity doesn't hurt, but I do wish the author had considered our developments here (at riscv/riscv-v-spec). His material appears to derive from Patterson-Waterman's 2017 book (and sigar

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