|
Re: Please check new Google calendar for new vector TG meeting link
Nick fowarded the old deprecated calendar.
https://sites.google.com/a/riscv.org/risc-v-staff/home/tech-groups-cal Is the new unified tech group calendar. It is very hard to find, we're working on improving that. Krste | Hi Cohen,On Fri, 25 Sep 2020 08:58:25 -0700, "Nick Knight" <nick.knight@...> said: | I can see the calendar here: | https://lists.riscv.org/g/tech-vector-ext/calendar | Unfortunately, due to a conflict I can only rarely attend the TG meeting. | Best, | Nick | On Fri, Sep 25, 2020 at 8:27 AM CDS <cohen.steed@...> wrote: | Can you publish a link to what the Google Calendar is, or the TG meeting | link? There are no links on this site to any of that information. |
|
|
|
|
Re: Please check new Google calendar for new vector TG meeting link
CDS <cohen.steed@...>
It looks like there are two calendars – one on the risc-v site, and one on google (someone else sent to me). And the ZOOM meeting invites are not the same between them :\
-Cohen
From: Nick Knight <nick.knight@...>
CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.
Hi Cohen,
I can see the calendar here: https://lists.riscv.org/g/tech-vector-ext/calendar
Unfortunately, due to a conflict I can only rarely attend the TG meeting.
Best, Nick
On Fri, Sep 25, 2020 at 8:27 AM CDS <cohen.steed@...> wrote:
|
|
|
|
Re: Please check new Google calendar for new vector TG meeting link
Hi Cohen, I can see the calendar here: https://lists.riscv.org/g/tech-vector-ext/calendar Unfortunately, due to a conflict I can only rarely attend the TG meeting. Best, Nick
On Fri, Sep 25, 2020 at 8:27 AM CDS <cohen.steed@...> wrote: Can you publish a link to what the Google Calendar is, or the TG meeting link? There are no links on this site to any of that information.
|
|
|
|
Re: Please check new Google calendar for new vector TG meeting link
CDS <cohen.steed@...>
Can you publish a link to what the Google Calendar is, or the TG meeting link? There are no links on this site to any of that information.
|
|
|
|
Re: Mask Register Value Mapping
David Horner
You got my thumbs up! Definitely "something similar" and better that my more cryptic proposal. Thanks you Cohen for raising these concerns and Nick for moving
this along so quickly. On 2020-09-24 12:48 a.m., Nick Knight
wrote:
|
|
|
|
Re: Mask Register Value Mapping
The existing draft used the notation v0.mask[i] in dozens of places to denote subscripting of a mask vector (bit granularity). I opted to use the existing notation uniformly, rather than switch to David's proposed v0[i].m . Happy to debate. The .mask suffix was not previously used in unsubscripted contexts, and I did not introduce it there. My PR is here: https://github.com/riscv/riscv-v-spec/pull/572 . Let's move further discussion to Github. Best, Nick Knight
On Wed, Sep 23, 2020 at 3:11 PM Andrew Waterman <andrew@...> wrote:
|
|
|
|
Re: Mask Register Value Mapping
Andrew Waterman
On Wed, Sep 23, 2020 at 2:45 PM David Horner <ds2horner@...> wrote:
👍
|
|
|
|
Re: Mask Register Value Mapping
David Horner
On Wed, Sep 23, 2020, 15:10 CDS, <cohen.steed@...> wrote:
Or my preference a similar annotation that explicitly identifies it as a mast bit: vs2[i] + vs1[i] + v0[i].m Or similar.
|
|
|
|
Re: Mask Register Value Mapping
CDS <cohen.steed@...>
Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only. vs2[i] + vs1[i] + v0[i] which can easily be misleading to the reader - while 'i' has the same value for all three terms, the first two indicate a SEW bit field, whereas the final term indicates a single bit. Suggestions: include a reminder that v0[i] entries are a single bit under the opening comment in the code block ("Produce sum with carry."); Set a reminder at the bottom of the description section before starting the code text, or indicate a comment on the code line "#Vector-vector-bit".
|
|
|
|
Re: Mask Register Value Mapping
I believe so: I am not aware of any proposals to reintroduce MLEN.
On Tue, Sep 22, 2020 at 12:34 PM CDS <cohen.steed@...> wrote: Thank you Andrew and Nick.
|
|
|
|
Re: Mask Register Value Mapping
CDS <cohen.steed@...>
Thank you Andrew and Nick.
To avoid having to repeat this question later, is it the intent moving forward (beyond "this version of the spec" being 0.9 stable) that this will hold true in the same format - at least, as of today?
|
|
|
|
Re: Mask Register Value Mapping
Hi Cohen, I think the "LSB references" are carryovers from pre-0.9 versions, when MLEN > 1 was possible. I can put together a PR to fix this later tonight, unless someone else gets to it sooner. Best, Nick Knight
On Tue, Sep 22, 2020 at 12:25 PM CDS <cohen.steed@...> wrote:
|
|
|
|
Re: Mask Register Value Mapping
Andrew Waterman
It is the case that mask elements are always one bit wide in this version of the spec. Removing the “.LSB” holdovers will improve clarity.
On Tue, Sep 22, 2020 at 12:25 PM CDS <cohen.steed@...> wrote:
|
|
|
|
Mask Register Value Mapping
CDS <cohen.steed@...>
From 0.9 stable spec, 5.3.1, table (no number), vector masking is referred to as having LSB. This suggests, yet does not require, that the mask field for each element is greater than bit-size 1. From same spec, 4.6.1, each element mask bit is given an explicit location, as a single bit. And yet, for individual operations, the LSB reference is still intact - such as in section 12.4 (Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions).
|
|
|
|
Re: V-ext white paper?
Yes, but only after it heads into ratification.
toggle quoted messageShow quoted text
There are at least two papers. 1) outline the design for people, 2) document the history and development process Krste
|
|
|
|
Re: V-ext white paper?
count me in
Hi team, Do we have a plan to write a V-extension white paper? Is there any interest? I'm thinking along the lines of ARM's SVE paper in IEEE Micro '17. I don't know if this is feasible or appropriate for a RISC-V working group. And I imagine our organizations will write individually about our own implementations. But it might be nice to collaborate on a general paper, post-ratification, presumably. Best, Nick Knight _._,_._,_ WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer
|
|
|
|
V-ext white paper?
Hi team, Do we have a plan to write a V-extension white paper? Is there any interest? I'm thinking along the lines of ARM's SVE paper in IEEE Micro '17. I don't know if this is feasible or appropriate for a RISC-V working group. And I imagine our organizations will write individually about our own implementations. But it might be nice to collaborate on a general paper, post-ratification, presumably. Best, Nick Knight
|
|
|
|
Vector TG minutes for 2020/9/18
Date: 2020/9/18
Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~17 Current issues on github: https://github.com/riscv/riscv-v-spec #551 Memory orderings scalar-vector #534/5 Element ordering ----------------------------------- The following proposal was put forward and was agreeable to group. Vector unit-stride and constant vector memory accesses (both load and store) would always be unordered by element. Indexed accesses would be supplied in both ordered and unordered forms. Where ordering is required, software has to use an indexed instruction. Existing encoding is retained in mop[1:0], with the previously reserved load mop[1:0] encoding now allocated to unordered gather. Strided operations now treated as unordered. Loads Old New mop[1:0] 0 0 unit-stride (ordered) VLE unit-stride (unordered) VLE 0 1 reserved --- indexed (unordered) VLUXEI 1 0 strided (ordered) VLSE strided (unordered) VLSE 1 1 indexed (ordered) VLXEI indexed (ordered) VLOXEI Stores Old New mop[1:0] 0 0 unit-stride (unordered) VSE unit-stride (unordered) VSE 0 1 indexed (unordered) VSUXEI indexed (unordered) VSUXEI 1 0 strided (unordered) VSSE strided (unordered) VSSE 1 1 indexed (ordered) VSXEI indexed (ordered) VSOXEI (The mnemonics were not discussed at length in meeting, and a slightly different scheme is given here. The indexed operations have a "U" or "O" to distinguish between unordered and ordered. This is a little less consistent, as could argue that unordered indexed operations don't need a U to match others, but this approach minimizes disruption to existing software.) For unordered instructions (mop!=11) there is no guarantee on element access order. For segment loads and stores, the individual element accesses within each segement are unordered with respect to each other. If the accesses are to a strongly ordered IO region, the element accesses can happen in any order. Stride-0 Optimizations ---------------------- We also discussed stride-0 optimizations. The proposed scheme is that if rs1=x0, then an implementation is allowed to only perform one memory read and replicate the value to all destination elements but may the read the location more than once. Similarly, a store might combine one or more elements and do fewer writes to memory. With a zero-valued stride in a register rs1!=x0, i.e., x[rs1]==0, the implementation must perform all accesses (but these will be unordered). It was noted the compiler must be aware not to convert a known stride of 0 into use of x0 if all memory accesses are required. If it is desired to perform multiple repeated ordered accesses to a non-idempotent memory region (e.g., popping a memory-mapped FIFO), then an ordered gather should be used targeting the single address. When a segment straddles a PMA boundary, the segment accesses must obey the PMA constraints associated with each constituent element's address for accesses to that element. Ordered AMOs ------------ The current PoR only has unordered AMOs. If was discussed whether ordered AMOs are desirable, but there were few clear examples where this would be useful, and so these are not planned for v1.0. Element-Precise Exception Reporting ----------------------------------- There was discussion around allowing vector stores to have updated some locations in memory corresponding to elements before the element that raises a synchronous exception. The proposal was to allow these additional stores in idempotent memory regions. Stores to non-idempotent memory regions must not occur for elements past an element reporting an exception. #493/510/532 Opaque vstart -------------------------- There was brief discussion around opaque vstart. Given the relaxation of memory access ordering, it was felt less critical to support opaque vstart, but was suggested to allow this in a subset of the base architecure (treating non-opaque vstart in V as an extension). However, it was also noted that opaque vstart alone will rarely be sufficient to support resumable traps, and in general additional mechanism will be required to save and restore microarchitectural state in complex processors with imprecise traps.
|
|
|
|
Please check new Google calendar for new vector TG meeting link
Krste
|
|
|
|
Vector Task Group minutes for 2020/9/4 meeting
Date: 2020/9/4
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: Spec formatting. The new formatting has been merged in, and the new build flow was discussed. #551 Memory orderings scalar-vector #534/5 Element ordering Discussion continued around memory ordering and determing the correct set of instructions to provide- with discussion to continue on list.
|
|
|