I added the change to add a vcsr including FP fields (this came out much cleaner I think) - please check over. Another minor change was to fold in the suggestion to move VS to a two-bit wide gap

Special lmul code in vsetvl{i} to derive LML from existing SEW/LMUL and provided sew code. As mentioned in the TG we suggested widen LMUL to 3 bits with 7 (explicit) states.

I left the encoding unspecified in the proposal. That was intentional as I saw various tradeoffs. However, I now recommend the codes be in order of increasing VLMAX value as so:

Hi all, we have updated to version 0.8 of V-ext our LLVM-based experimental compiler and the intrinsics reference. EPI builtins and examples:

Date: 2020/2/21 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~13 Current issues on github: https://github.com/riscv/riscv-v-spec Note, the Zoom meeting details have

Date: 2020/3/6 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~21 Current issues on github: https://github.com/riscv/riscv-v-spec Note, the Zoom meeting details have changed.

... We've discussed before, but allowing the *-agnostic options means code can be written and tested on an implementation that supports them and then fail on an implementation that maps them to #1.

| On 3/6/20 6:22 PM, Krste Asanovic wrote: [...] || #367 Tail Agnostic || The discussion reviewed the proposal that long temporal vector || registers with renaming could be handled using vector length

It doesn't look like all these issues were addressed either on mailing list or on github tracker. In general, it is much better to split feedback into individual topics. I'm responding all-in-one

We have seen very efficient FFT execution without adding new instructions, but there is interest in a layer of DSP extension on top of the base vector ISA. One goal of the EDIV extension would be

On a context switch, the underlying physical registers that hold spill values need to be saved/restored to memory, as well as the associated rs1 values. This means we need extra instructions to

I'm sending out to the correct mailing list a copy of the revised issue #393. (link: https://github.com/riscv/riscv-v-spec/issues/393 ) This was

I am developing sparse matrix codes using the vector extension on RISCV32 using SPIKE simulator. Based on my understanding of the spec thus far, I wanted to ask a couple of questions about the spec. I

1. A vector register is deliberately used as the destination of reductions. If the destination is a scalar register, then tight coupling between the vector and scalar units would be necessary,

Indices must be able to represent general pointers in some cases (e.g. vectorizing (*(x[i]))++ instead of y[x[i]]++), so implicitly scaling the indices causes problems, particularly when misaligned

I am not sure I replied right (I hit reply to sender but not sure who I responded to, learning to work with the list). But thanks for quick replies. 1. Yes, understood about the scalar destination

possibly vslide1up after every reduction, producing a vector of reductions (possibly in backwards order, unless you rearrange your outer loop order). I'm not suggesting that you use vrgather to

Thank you for the vslide1up suggestion. I might use this with loop unrolling. Best Regards Nagendra

Guy pointed out to me that, since several V ISA-design issues have been punted to an eventual 64-bit instruction encoding, we should consider recording them somewhere. I've set up the github wiki for