Hi Rich, The reduction operations retain the `.vs` suffix: https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#16-vector-reduction-operations Best, Nick Knight

On 2020-07-01 4:33 a.m., krste@... wrote: No problem, happy you did. The very special nature and functionality of vsetvli justifies considering special encoding.

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

Forgive top posting, but the email was long and I want to bring key points forward for others. #458/460 propose restricting allowed register numbers in a vsetvli to give more bits to future vsetvli

I think I understand how I confused the situation. Issue #458 introduced idea of using rd and rs1 values to encode more bits for vsetvli. I proposed that this become the only vsetvli format. Krste

tech-vector-ext got dropped somehow, adding again. We have to keep technical discussion on tech-vector-ext public mailing list. | On Jun 30, 2020, at 12:35 AM, Roger Espasa

For 1.0, we are just trying to fix vsew, vlmul, vma, and vta (and also vill in vtype, but that’s out of vsetvli immediate range). I think it’s clear that vma and vta are not going to change very

On 2020-06-29 10:36 a.m., Krste Asanovic wrote: It is a planned extension, that even if not implemented as currently proposed it will likely consume at least 2 bits in vtype.

Can you focus on what would not be possible if we ratified current proposal. Remember EDIV is not in 1.0 and Vlmul=100 is reserved Krste

minor typos; substantial correction: On 2020-06-29 10:12 a.m., David Horner via lists.riscv.org wrote: also throughout the email vd should be rd vs1 should be

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

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’

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

The warehouse is the computer. Modern cloud companies have warehouses that hold 50,000 severs at 30-60 MegaWatts for air cooled or water cooled clusters Dave

How do you cool a 28MW computer? On Thu, 2020-06-25 at 14:28 -0700, David Patterson via lists.riscv.org wrote: -- Derek Atkins Chief Technology Officer Veridify Security - Securing the Internet of

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

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

The wide register being the destination, correct? Not sure I follow this, which two registers? If physical registers, then no. That design was the v0.8 method of vertical cycling through physical

Hi David, If I try to compare this to the current proposal, it seems to me there are two major differences. ** A layout difference in the wide registers where elements alternate between two