Reminder we have our TG meeting this Friday morning. Details on member calendar. Krste

I made this into its own thread as well. I think there is a parallel in the in-register/in-memory issue and memory consistency model/methods. The complexity of consistency models and methods is enormo

I have some suggestions for the reasons for moving from v0.8 vertical striping to v0.9 horizontal SLEN (interleave) Under v0.8 A) when vl < VLEN/SEW*LMUL the top elements are not filled. This can lead

I believe this can be weakened to required: select-able distribution patterns that are sufficiently compatible that they avoid fragmenting the software ecosystem.

I've made a major update to mask encoding, pushed to repo. The earlier change to support fractional LMUL effectively "broke" the earlier mask encoding. The new scheme is simpler, but is different. Ple

We’ll be meeting tomorrow morning. Meeting details on member calendar. Krste (on iPhone, forgive terseness)

Date: 2020/5/1 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~20 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed: #440

I've been busy trying to get to a draft of 0.9. I just pushed a set of memory instructions with "effective element width" encoded statically, though the text needs more read through and checking. We'l

The aspect that will probably be most problematic for programmer is the loss of memory mapping paradigm. Whereas adjacent bytes in memory are in the same or adjacent words (ditto for half words and do

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 n=1,2,4.

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 a subst

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 effective ele

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 instructions requir

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 Att

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 strawma

Date: 2020/4/03 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~15 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed: #354/362 The following iss

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 applicat

Hi, Nick That is a good suggestion for my code, thank you very much. But I develop my code depend on spec 0.7.1. The q-wide instructions had not been added to the spec. And I am confused with the upda

I agree with your point. But nowadays, the spec is not stable, and there is no target SOC to verify it. So, in my opinion, the number of instructions is an important indicator at present. 发件人: Bruce H

Hi Damon, Thanks for providing a concrete example! I think you can improve the performance of your first example (non-widening loads). Instead of immediately widening, you could instead perform your s