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

I haven’t seen any burning issues come by, and am still trying to clean up spec. So unless someone has agenda items, I’m canceling meeting tomorrow, Krste

I’m still working on spec cleanup and I don’ t have any major outstanding issues to discuss, so will cancel the TG meeting this week. Please bring up any burning issues on this mailing list, Krste

Date: 2021/03/26 Task Group: Vector Extension Chair: Krste Asanovic Vice-Chair: Roger Espasa Number of Attendees: ~10 Current issues on github: https://github.com/riscv/riscv-v-spec A short meeting di

We'll meet again in usual slot. The main discussion topic will be #545. Please read the issue thread on github. Summary: The proposal is to move vector AMOs from their current encoding to leave space