I see that section 7.5 of the vector spec currently says: When rs2=x0, then an implementation is allowed, but not required, to perform fewer memory operations than the number of active elements,

FYI, I'm working with Elisa Sawyer and others on a style and content guide for extension proposals, mostly based on the excellent bitmanip v1.0.0-rc1 draft. That draft includes a table like the one

Hi Krste, The descriptions of Zvl* look good. A couple of comments: * The V description says vector length greater than or equal to 128. Should it instead refer to Zvl128b? * I wonder if there

I added vector length extensions to spec. Please review, Krste | Hello Guy, | It definitely would be good for Zve to be a strict subset of V. I think that means the same thing as that any binary

Date: 2021/07/09 Task Group: Vector Extension Chair: Krste Asanovic Vice-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github: https://github.com/riscv/riscv-v-spec We had a short

Hello Guy, It definitely would be good for Zve to be a strict subset of V. I think that means the same thing as that any binary that runs on Zve will run correctly on Z. But I’m not seeing how

Hi, The way 18.1 and 18.2 currently read in the V spec is a bit confusing. It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor". 1)

I apparently missed the meeting that I thought was at noon eastern. There are of course the remaining open for v1.0 issues. I gather what was discussed was if we could reasonably move to public review

just to qualify, I think we are talking about RVA22 (application target) and not RVM22 (microcontroller target).

Mentioned by Krste in the meeting: processor profile already requires VLEN >= 128.

A topic to discuss: lower bound on VLEN. The upper bound is helpful but even VL-agnostic code sometimes wants at least 128 bits. Example: N parallel instances of AES (16 bytes each), or N 128-bit

For discussion: The text states: reporting an error and terminating execution is the appropriate response. Issue #598 to be resolved after v1.0 and issue #364 which is tagged with "resolve for

We’ll meet tomorrow to see if there are any remaining concerns before going Into public review, Krste

-----Original Message----- From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic Sent: Friday, July 2, 2021 12:53 PM To: tech-vector-ext@... Subject: [RISC-V] [tech-vector-ext]

Date: 2021/07/02 Task Group: Vector Extension Chair: Krste Asanovic Vice-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github: https://github.com/riscv/riscv-v-spec We discussed

Based on feedback, we'll have a vector TG meeting tomorrow to address concerns. Details in usual place in Google calendar, Krste

I’ve taken a stab at reducing the number of instructions in my RVV-lite proposal. The overriding goal, in my mind, is to preserve forward software compatibility so the ecosystem doesn’t need to

Hi Everyone, wanted to continue this interesting discussion. Noticed that the ZVE* Extensions are listed now on the vspec.adoc:

I did not expect that this meeting, of all meetings, would be cancelled. So I’ll send my comments by email now rather than discussing an important one at the meeting and filing issues for minor

I am disappointed that the meeting was cancelled. I am concerned that jnk0le's contributions/concerns, in particular, have been dismissed and to the extent that they were objections to