| 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

OK. Again thanks. I will generate a few versions and compare incrementally. Will report the anomalies if they show up in your weekend efforts.

| 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