I added a note on this issue to spec: NOTE: When migrating a software thread between two harts with different microarchitectures, the `vstart` value might not be supported by the new hart microarchite

I trust this is not just noise. A laundry list of concerns Assess objectives and those met as we approach v1.0 of RVV Polymorphism has not made it into RVV V0.9 Tagging registers with a datatype is no

TL;DR; I make clarifications on meeting minutes. I propose we present 1) a relaxed RVV memory/process model, more relaxed than we believe current implementations require for optimal performance. Appli

Sorry for what may be a question with an answer that may be obvious to those that have been at all the meetings: Have the vector-scalar instructions (.vs) been eliminated from the vector extensions? B

minor typos; substantial correction: also throughout the email vd should be rd vs1 should be rs1 And vs2 is completely bogus. Sorry I didn't catch this sooner.

I disagree that #460 should be deferred until after V1.0. Although I agree that the proposal itself can be implemented in a manner consistent with the current vsetvli definition, I disagree that the l

I don't agree that #478 should be closed for the reasons given. I do agree that another approach might be better to superseded that which was originally proposed. But I do not agree with the proposed

I made a pass over the spec repo, adding red labels for “resolve for v1.0’ , versus yellow labels for "resolve after v1.0”. I also cleaned up and closed some other issues. "Resolve after’ should not b

Date: 2020/6/26 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~15 Current issues on github: https://github.com/riscv/riscv-v-spec Thanks to all the par

In case you missed it, yesterday the HPC community announced the "world's fastest computer" (based on Linpack) is based on the Fujitsu A64FX, which is the first to implement the ARM Scalable Vector Ex

We’ll be meeting later today per the member calendar, Krste

TL;DR: I'm leaning towards mandating SLEN=VLEN layout, at least for application processor profiles. Regarding register layout, I thought it would be good to lay out the landscape and comparison with o

The whole register loads and stores in section 7.9 of the spec are currently specified as having an element size of 8-bits. Could they be extended to cover all sizes instead of just the 8-bit size? It

Attached below. Also a reminder we'll be meeting again on Friday per group's calendar info. Krste Date: 2020/6/19 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of At

We agreed to meet again today (Friday) in usual slot - see member calendar for details, Krste Date: 2020/6/12 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attend

Hi all, In this page I would like to discuss about fault-only-first indexed load instructions since we have certain using cases, for example, SPEC CPU 2006 4.1.bzip2 src/blocksort.c:line 712. For faul

I finally pushed minutes of last meeting (attached) Our next meeting is later today (Friday Jun 12) with details available on task group calendar. I’m preparing a note on vector register layout, which

There hasn't been any traffic on this feed about vector layout, and specifically about v0.9 SLEN size standards. So I will add my thoughts here with the hopes that I will not take excessive time durin

Date: 2020/5/15 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~20 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed: # M

Hi, We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more fee