I’ve made a frozen release of version 1.0 ready for public review. The release is tagged: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0 and I’ve attached pdf below. The main repo has now adv

I've finally finished an extensive pass over the whole spec, and believe it should be ready for public review but given that it's late on a Friday, I would like to give at least one more sleep cycle b

Added explicit statement to spec for this case. There was a wrap-around statement for single-width but not for widening reductions. Krste | As a 2*SEW scalar from element 0 of vs1 is added to the sum

Thanks for the suggestions. I tried to clean up and clarify this section: https://github.com/riscv/riscv-v-spec/commit/3cc98373f954df996c2d7973ef0fc38bc866f620 Krste >>>>> On Wed, 8 Sep 2021 15:25:39

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 that

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 mee

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

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 sever

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

There have been no substantial objections raised on the v1.0-rc1 draft, so I will cancel the meeting tomorrow. There are some minor suggestions and edits (thank you!), and I will incorporate these int

Unless there are significant issues raised by the group on the v1.0-rc1 spec, the intent is to go into public review on June 25th, so please make sure to give any feedback before then. There are a few

I've just tagged the first release candidate for v1.0 of the vector spec in github. PDF attached below. I've included the TG agreed updates and handled almost all of the outstanding issues for v1.0. T

If there was no cost, then supporting VLEN=64 on general apps processor profile would be a good thing to do. But not allowing standard software to assume VLEN>=128 imposes a non-trivial impact on bigg

This is the requirement for app processors, which are not generally small cores. Most competing SIMD extensions are at least 128b per vector register. Lower performance on codes that work well on othe

see github issue #550 Krste

| could an extension just change state like the number of vector registers? | Don't understand tbis question - please elaborate. Krste

Section 4.5, Krste | On Wed, Jun 2, 2021 at 8:38 AM Andrew Waterman <andrew@...> wrote: | It’s actually not fundamental to the ISA design that VLEN >= ELEN. An | implementation with VLEN=32 cou

We do allow supported SEW to vary with LMUL, so implementation can support single-width operations on SEW=64. See section 4.5, Krste | So, (on a 32x 32-bit vector register machine) the widening and na

The VLEN>=128 constraint is only for the application processor "V" extension for the app profile - not for embedded vectors which can have VLEN=32. From spec Introduction: ' The term base vector exten

Actually, vfirst,m can be implemented with an early out on long temporal vector machines, whereas vpopc.m has to process all bits. If the common case for the input data is that all bits would be set/c