regarding vector reduction destination: the V spec seems to allow for really large vector machines with thousands of vector elements. I'm not sure what the right bit width for the field with the

It appears I can not edit the wiki. But I can clarify one item. Regarding "Indexed memory accesses that implicitly scale the index by SEW/8": Explanation: In scientific sparse matrix codes (and

My current "long instruction encoding" proposal has an example encoding for 64-bit V extension

Hi all, I am not sure if these require 64-bit encoding, but I am interested in extended data types, especially signed-integer-complex, single-precision floating-point complex, and unums.

Anecdote: One of my initial inspirations for working on dynamic out of order scheduling was to support incremental time pipeline vectors, both scatter/gather and stride. I.e. the P6 RS began

Since this is happening to an already-slow memory access, I would guess performing checks in software would be the better way to go. There is no current talk about aborting a long-running indexed

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

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

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

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

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

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

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,

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'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

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

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

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

| 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

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