I managed to swap the file names around, and sent earlier week's minutes instead of last week's. Here's the correct minutes from last week (also fixed in repo). Krste Date: 2020/7/10 Task Group: Vecto

A belated posting of minutes from last week's meeting. We'll be meeting again today as per member calendar, Krste Date: 2020/7/03 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Esp

We’ll have our regular TG meeting in a few hours per member calendar. We’ll continue to clean up remaining issues for v1.0, Krste

I messed up the links: the list of open unlabeled issues is here: https://github.com/riscv/riscv-v-spec/issues?q=is%3Aissue+is%3Aopen+no%3Alabel

There are 19 open issues that aren't yet labeled. Does it make sense that those who will be on the call review them with an idea to categorize as for or after V1.0? That should also determine those th

Date: 2020/7/03 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~6 Current issues on github: https://github.com/riscv/riscv-v-spec This call was sparsely

I realize it is a holiday in US today, but I will hold a vector TG meeting for those who can attend in usual slot as given in member calendar. I've been updating the spec with earlier decisions, and t

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