The number of instructions does not necessarily correspond to the speed, and especially not to the PPA or efficiency. Making the load/store simpler might save enough area to make it as or more energy

Hi，all I have some applications about byte/halfword/word vector load/stores, like gemm, direct convolution and son on. For 3x3 direct convolution, the code without byte/halfword/word vector load/store

We will be meeting again this morning. I hope to focus on closing on features for upcoming 0.9 release. Krste

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

I've been wading through the fractional LMUL discussion on github but believe the simple basic solution below meets the immediate needs, without blocking possible reuse of unused register fields later

This observation is a bit of a memory side issue but is tied to vector indexed loading semantics. The problem that I see is that my address offsets in the vector indexed load instruction are rather la

Date: 2020/3/20 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~20 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed: #367, #393 The following i

Maybe this has been stated already, and I just haven't seen it, but it seems like there's a constraint with fractional LMUL that wasn't there before. The compiler must ensure that: LMUL >= SEW/ELEN. I

I neglected to send an earlier reminder, but the vector TG meeting will be happening today per member calendar details, Krste

This is the fourth installation of the Simple Fractioanl LMUL design. It does not yet address SLEN and a suggestion for a fractional SLEN (fracSLEN). It should however clarify the ramifications of the

I am sending out the partial description of the next itteration for the Simple Fractioanl LMUL design. It is incomplete because I only recently clarified in my own mind a means to represent the concep

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 requested at the last TG meeting. I believe it is consi

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

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 belo

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 to s

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.

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 changed.

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: https://repo.hca.bsc.es/gitlab/rferrer/epi-builtins-ref Co

In the last meeting, we discussed a problem that would be introduced if we were to drop the fixed-size (b/h/w) variants of the vector load/stores and only have the SEW-size (e) variants. From the minu