| Thank you very much for this. | I started a pull request, but was including as an extension and still debating the best way to incorporate. | Would it be possible to generate a pdf for what is now

First some observations from the revised LMUL. *1 The format for a given SLEN and SEW is the same for all LMUL>=1 *2 LMUL=n is equivalent to LMUL=2 * n with vl < 1/2 vlmax at that level, for

Thank you very much for this. I started a pull request, but was including as an extension and still debating the best way to incorporate. Would it be possible

For those not following on github: On 2020-04-19 1:00 a.m., Krste Asanovic wrote: .... SEW and LMUL values are essential to correct code execution regardless

I sent on the wrong email list, so I resend hre. The cost of narrow to wide is much easier to handle with vlb than with vector arithmetic instructions. In Bob’s example, it is one instruction

First thoughts below - as a response to #424 and - we need only consider SEW = LEW (new) and 1/2LEW (POR) On 2020-04-19 1:00 a.m., Krste Asanovic wrote:

I added my proposal to github: https://github.com/riscv/riscv-v-spec/issues/425 appended below for those not following github Krste This proposal is a modification of earlier idea to add

On 2020-04-18 3:14 p.m., Krste Asanovic wrote: As I had asked that pagan question of opcode space I thought I should try to address the problem: I opened issue

Also a reminder that the next meeting will be a half hour earlier. Please check the group's calender for details. Krste Date: 2020/4/17 Task Group: Vector Extension Chair: Krste Asanovic Number of

I believe I believe these widths are the appropriate ones. See the explanation above. The rationale being widening (and narrowing) instructions are already SEW based, so are single SEW instructions

I really like the fact that this solves indexed. It's a pretty good proposal overall, and I think it beats adding "quad" extension and then a debate over "quad-with-add", "quad-with-sub",

I wonder if we might encode EEW/SEW in the instruction instead of encoding EEW. We might encode SEW/4, SEW/2, SEW, and 2*SEW as the EEW widths. Another alternative would be to have an additional

Agree. It seems quite nice. Bill On 4/16/20 8:30 PM, Bruce Hoult wrote:

On 2020-04-16 11:02 p.m., Krste Asanovic wrote: What of SEW scaling factor instead. 1/4,1/2,1 and 2. This allows a much expanded dynamic range and addresses most scaling concerns.

Nice.

There are two separate issues noted with the proposal to fixed-size vector load/stores. One is the additional vsetvli instructions needed, and the second is the additional widening

Previous issues I opened on fractional LMUL were exploratory, suggesting various ways to encode and enable the feature. The latest 4 issues opened on github are specific proposals based on the

I agree, It's more important to gather and evaluate actual application kernels. Is there such an effort on-going? I further agree to the implicit idea that much, even most, of the

These are basic operations, not application kernels. It's easy to call out missing instructions when considering individual operations. It's more important to gather and evaluate actual application

Hi, all I have a problem about the usage of VectorAMO Operations. In the spec, there is only two sentences to describe the usageof Vector AMO Operations. Who have the concrete sample or other