tech-vector-ext@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: 64-bit instruction encoding wish list

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

By Claire Wolf <claire@...> · #47 ·

Re: 64-bit instruction encoding wish list

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

By Nagendra Gulur · #46 ·

Re: 64-bit instruction encoding wish list

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

By Claire Wolf <claire@...> · #45 ·

Re: 64-bit instruction encoding wish list

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.

By Richard Newell · #44 ·

Re: Vector Indexed Loads - Partial Return?

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

By Andy Glew Si5 · #43 ·

Re: Vector Indexed Loads - Partial Return?

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

By Guy Lemieux · #42 ·

Vector Indexed Loads - Partial Return?

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

By Nagendra Gulur · #41 ·

64-bit instruction encoding wish list

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

By andrew@... · #40 ·

Re: A couple of questions about the vector spec

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

By Nagendra Gulur · #39 ·

Re: A couple of questions about the vector spec

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

By Guy Lemieux · #38 ·

Re: A couple of questions about the vector spec

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

By Nagendra Gulur · #37 ·

Re: A couple of questions about the vector spec

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

By andrew@... · #36 ·

Re: A couple of questions about the vector spec

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,

By Guy Lemieux · #35 ·

A couple of questions about the vector spec

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

By Nagendra Gulur · #34 ·

issue #393 - Towards a simple fractional LMUL design.

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

By David Horner · #33 ·

Re: [tech-vector-ext] Some proposals

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

By Guy Lemieux · #32 ·

[tech-vector-ext] Feedback on RISC-V V-extension (FFTW3 and Chacha20)

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

By Krste Asanovic · #31 ·

[tech-vector-ext] Some proposals

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

By Krste Asanovic · #30 ·

Re: Minutes of 2020/3/6 vector task group meeting

| 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

By Krste Asanovic · #29 ·

Re: Minutes of 2020/3/6 vector task group meeting

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

By Bill Huffman · #28 ·

841 - 860 of 887

Home Hashtags Subgroups Terms