|
Re: Vector TG meeting minutes 2020/9/25
I am in favour of effectively weakening the scalar/vector vector/scalar load/load order requirement.
However, this cannot be performed in isolation without regard to the rest of the RVWMO
I am in favour of effectively weakening the scalar/vector vector/scalar load/load order requirement.
However, this cannot be performed in isolation without regard to the rest of the RVWMO
|
By
David Horner
·
#434
·
|
|
Vector TG meeting minutes 2020/9/25
Date: 2020/9/25
Task Group: Vector Extension
Chair: Krste Asanovic
Co-Chair: Roger Espasa
Number of Attendees: ~14
Current issues on github: https://github.com/riscv/riscv-v-spec
Issues
Date: 2020/9/25
Task Group: Vector Extension
Chair: Krste Asanovic
Co-Chair: Roger Espasa
Number of Attendees: ~14
Current issues on github: https://github.com/riscv/riscv-v-spec
Issues
|
By
Krste Asanovic
·
#433
·
|
|
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
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
|
By
Krste Asanovic
·
#432
·
|
|
Re: Please check new Google calendar for new vector TG meeting link
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
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
|
By
CDS <cohen.steed@...>
·
#431
·
|
|
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
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
|
By
Nick Knight
·
#430
·
|
|
Re: Please check new Google calendar for new vector TG meeting link
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.
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.
|
By
CDS <cohen.steed@...>
·
#429
·
|
|
Re: Mask Register Value Mapping
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
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
|
By
David Horner
·
#428
·
|
|
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
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
|
By
Nick Knight
·
#427
·
|
|
Re: Mask Register Value Mapping
👍
By
Andrew Waterman
·
#426
·
|
|
Re: Mask Register Value Mapping
Or my preference a similar annotation that explicitly identifies it as a mast bit:
vs2[i] + vs1[i] + v0[i].m
Or similar.
Or my preference a similar annotation that explicitly identifies it as a mast bit:
vs2[i] + vs1[i] + v0[i].m
Or similar.
|
By
David Horner
·
#425
·
|
|
Re: Mask Register Value Mapping
Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.
This would create a phrase
vs2[i] + vs1[i] + v0[i]
which can easily be misleading to the reader -
Word of caution: there may be a utility/readability concern if the ".LSB" text is removed, only.
This would create a phrase
vs2[i] + vs1[i] + v0[i]
which can easily be misleading to the reader -
|
By
CDS <cohen.steed@...>
·
#424
·
|
|
Re: Mask Register Value Mapping
I believe so: I am not aware of any proposals to reintroduce MLEN.
I believe so: I am not aware of any proposals to reintroduce MLEN.
|
By
Nick Knight
·
#423
·
|
|
Re: Mask Register Value Mapping
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
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
|
By
CDS <cohen.steed@...>
·
#422
·
|
|
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
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
|
By
Nick Knight
·
#421
·
|
|
Re: Mask Register Value Mapping
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.
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.
|
By
Andrew Waterman
·
#420
·
|
|
Mask Register Value Mapping
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
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
|
By
CDS <cohen.steed@...>
·
#419
·
|
|
Re: V-ext white paper?
Yes, but only after it heads into ratification.
There are at least two papers. 1) outline the design for people, 2) document the history and development process
Krste
Yes, but only after it heads into ratification.
There are at least two papers. 1) outline the design for people, 2) document the history and development process
Krste
|
By
Krste Asanovic
·
#418
·
|
|
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
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
|
By
swallach
·
#417
·
|
|
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
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
|
By
Nick Knight
·
#416
·
|
|
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
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
|
By
Krste Asanovic
·
#415
·
|