TL;DR: I'm leaning towards mandating SLEN=VLEN layout, at least for application processor profiles. Regarding register layout, I thought it would be good to lay out the landscape and comparison with o

The whole register loads and stores in section 7.9 of the spec are currently specified as having an element size of 8-bits. Could they be extended to cover all sizes instead of just the 8-bit size? It

Attached below. Also a reminder we'll be meeting again on Friday per group's calendar info. Krste Date: 2020/6/19 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of At

We agreed to meet again today (Friday) in usual slot - see member calendar for details, Krste Date: 2020/6/12 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attend

Hi all, In this page I would like to discuss about fault-only-first indexed load instructions since we have certain using cases, for example, SPEC CPU 2006 4.1.bzip2 src/blocksort.c:line 712. For faul

I finally pushed minutes of last meeting (attached) Our next meeting is later today (Friday Jun 12) with details available on task group calendar. I’m preparing a note on vector register layout, which

There hasn't been any traffic on this feed about vector layout, and specifically about v0.9 SLEN size standards. So I will add my thoughts here with the hopes that I will not take excessive time durin

Date: 2020/5/15 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: # M

Hi, We, EPI, SiPearl, and SiFive, have come out with a RFC for vector intrinsics. Although there are still some issues under discussion, we think it is time to publish the document to collect more fee

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