Date   

Re: FYI: ARM vs. RISC-V vector extension conmparison

Bruce Hoult
 

Yeah. I posted this link to our reddit /r/riscv four weeks ago and made a few comments about it.


It was posted on Hacker News yesterday and both Chris BOOM! Celio and I made a few comments and replies:


I have since at the author's request pointed him at the current spec. 


Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.

In one HN comment I pointed out that while having scaled indexed addressing mode for your vectors can be nice, those extra bits in a fixed size opcode do come at a cost.

> On a quick reread, I see a complaint that's entirely due to how
> ARM represents indexed load operations, which has absolutely
> nothing to do with the vector ISA whatsoever.

Not exactly true.

If you can use fancy addressing modes in your vector loads and stores and you have a fixed length 32 bit opcode (as both Aarch64 and RISC-V do[1]) then specifying an index register and how much to shift it by is taking up an extra 7 bits of your opcode (5 for register number, 2 for shift amount) vs an instruction that just specifies a base pointer register.

That means one instruction is taking up the opcode space that could otherwise be used by 128 different instructions instead.

That means either your vector ISA has fewer instructions and capabilities than it otherwise could have, or else it is taking up a lot more of the overall opcode space.




On Sat, May 8, 2021 at 9:07 AM Allen Baum <allen.baum@...> wrote:

Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.


Re: FYI: ARM vs. RISC-V vector extension conmparison

Nick Knight
 

I guess the publicity doesn't hurt, but I do wish the author had considered our developments here (at riscv/riscv-v-spec). His material appears to derive from Patterson-Waterman's 2017 book (and sigarch blog-post), and the architecture has evolved a bit since.


On Fri, May 7, 2021 at 5:06 PM Allen Baum <allen.baum@...> wrote:

Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.


FYI: ARM vs. RISC-V vector extension conmparison

Allen Baum
 


Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.


Re: GCC RISC-V Vector Intrinsic Instructions and #defines missing #defines

Kito Cheng
 

Hi Tony:

Could you create issues on github to track that?
https://github.com/riscv/riscv-gcc

Thanks :)

On Sat, Apr 10, 2021 at 9:14 AM Jim Wilson <jimw@sifive.com> wrote:

On Fri, Apr 9, 2021 at 3:40 PM Tony Cole via lists.riscv.org <tony.cole=huawei.com@lists.riscv.org> wrote:

I’m still new to RISC-V and the Vector extensions, so forgive me if I’ve missed something, the following have been fixed or noted before.

Also, am I sending this to the correct group for GCC RISC-V Vector Intrinsics? If not, who and how should I inform?

I would suggest filing an issue in the riscv/riscv-gnu-toolchain github tree. Put something like vector or rvv in the issue title to make it clear it is a vector related issue. The gcc support is not being actively worked on at the moment. LLVM is the current focus for all vector compiler support. Eventually someone may start working on the gcc vector support again. Meanwhile, bugs filed against the gcc vector support may or may not be fixed.

Jim


Re: GCC RISC-V Vector Intrinsic Instructions and #defines missing #defines

Jim Wilson
 

On Fri, Apr 9, 2021 at 3:40 PM Tony Cole via lists.riscv.org <tony.cole=huawei.com@...> wrote:

I’m still new to RISC-V and the Vector extensions, so forgive me if I’ve missed something, the following have been fixed or noted before.

Also, am I sending this to the correct group for GCC RISC-V Vector Intrinsics? If not, who and how should I inform?


I would suggest filing an issue in the riscv/riscv-gnu-toolchain github tree.  Put something like vector or rvv in the issue title to make it clear it is a vector related issue.  The gcc support is not being actively worked on at the moment.  LLVM is the current focus for all vector compiler support.  Eventually someone may start working on the gcc vector support again.  Meanwhile, bugs filed against the gcc vector support may or may not be fixed.

Jim


GCC RISC-V Vector Intrinsic Instructions and #defines missing #defines

Tony Cole
 

Hi all,

 

I’m still new to RISC-V and the Vector extensions, so forgive me if I’ve missed something, the following have been fixed or noted before.

 

Also, am I sending this to the correct group for GCC RISC-V Vector Intrinsics? If not, who and how should I inform?

 

 

 

I’m currently using: riscv32-unknown-elf-gcc (GCC) 10.1.0    (…/10.1.0–rvv-intrinsic-patch/bin/ riscv32-unknown-elf-gcc – version)

 

 

These (and probably others) don’t exist in the GCC compiler RISCV Vector intrinsics (the m8 versions):

 

        vint32m1_t vwredsum_vs_i16m8_i32m1 (vint32m1_t dst, vint16m8_t vector, vint32m1_t scalar, size_t vl);

        vint64m1_t vwredsum_vs_i32m8_i64m1 (vint64m1_t dst, vint32m8_t vector, vint64m1_t scalar, size_t vl);

 

They are listed in here: https://github.com/riscv/rvv-intrinsic-doc/blob/master/intrinsic_funcs/09_vector_reduction_functions.md

 

 

So, I’ve had to temporally change to (the m4 versions):

 

        vint32m1_t vwredsum_vs_i16m4_i32m1 (vint32m1_t dst, vint16m4_t vector, vint32m1_t scalar, size_t vl);
        vint64m1_t vwredsum_vs_i32m4_i64m1 (vint64m1_t dst, vint32m4_t vector, vint64m1_t scalar, size_t vl);

 

to get it to compile and work.

 

This may have already been fixed? Please let me know.

 

 

 

Also,

 

I was expecting to find some #defines for the rounding modes in riscv-vector.h, something like:

 

/* Vector Fixed-Point Rounding Mode Register vxrm settings

   Use with vwrite_csr(RVV_VXRM, RVV_VXRM_XXX) */

 

#define RVV_VXRM_RNU  (0) /* Round-to-nearest-up (add 0.5 LSB) */

#define RVV_VXRM_RNE  (1) /* Round-to-nearest-even */

#define RVV_VXRM_RDN  (2) /* Round-down (truncate) */

#define RVV_VXRM_ROD  (3) /* Round-to-add (OR bits into LSB, aka "jam") */

 

Tony Cole

CPU Consultant I RISC-V Cores, Bristol

E-mail: Tony.Cole@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件

 

 


Possible RISC-V Vector Instructions missing

Tony Cole
 

Hi Vector Team,

 

I’m new to RISC-V and the Vector extensions, so forgive me if I’ve missed something.

 

 

I have searched the specs, emails and git hub issues, but not found anything on this:

 

 

While writing some vector code using the vector intrinsics, I noticed some instructions missing that I expected to see:

 

I noticed there is no saturated reverse subtract version of vssub_vx, e.g. vsrsub_vx (or should it be vrssub_vx ?) and so no vsneg_v pseudo instructions

 

But there are the following integer/float reverse subtract instructions:

vrsub_vx

vfrsub_vf

 

and their pseudo instruction counterparts:

vneg_v

vfneg_v

 

For orthogonality there should be saturated versions of the above, but maybe there is not enough encoding space?

Or possibly remove vrsub_vx & vfrsub_vf to gain encoding space ??

 

Note: I wanted to use vsrsub_vx (to do vsneg_v), but instead achieved it by loading a vector with zero and performing vssub_vv.

 

Tony Cole

CPU Consultant I RISC-V Cores, Bristol

E-mail: Tony.Cole@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件

 


No vector task group meeting tomorrow

Krste Asanovic
 

I haven’t seen any burning issues come by, and am still trying to clean up spec.

So unless someone has agenda items, I’m canceling meeting tomorrow,
Krste


No vector TG meeting this week

Krste Asanovic
 

I’m still working on spec cleanup and I don’ t have any major outstanding issues to discuss, so will cancel the TG meeting this week.

Please bring up any burning issues on this mailing list,
Krste


Vector Task Group minutes from 2021/3/26 meeting

Krste Asanovic
 

Date: 2021/03/26
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~10
Current issues on github: https://github.com/riscv/riscv-v-spec

A short meeting discussing only:

#545 Vector AMO Encoding

The group discussed the issue with vector AMO overlapping the desired
space for future scalar AMOs. The group agreed with the proposal to
leave vector AMOs out of the v1.0 specification to allow time to
revisit the encoding taking into account the needs of scalar AMOs.


Vector Task Group meeting Friday March 26

Krste Asanovic
 

We'll meet again in usual slot.

The main discussion topic will be #545. Please read the issue thread
on github.

Summary: The proposal is to move vector AMOs from their current
encoding to leave space for scalar subword AMOs, and to drop vector
AMOs from the base application processor vector profile (they were
already excluded from Zve* subset profiles). We'll rework the
vector AMO encoding, but not in path for v1.0 ratification.

Krste


Vector Extension Task Group Minutes 2021/03/19

Krste Asanovic
 

Date: 2021/03/19
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~16
Current issues on github: https://github.com/riscv/riscv-v-spec

Issues discussed

#640 Bound on VLMAX/VLEN

Previously, we'd discussed making the upper bound on VLMAX part of
profile, but realization was that bound cannot be later increased in a
software-compatibile way without adding a new instruction, so is
effectively part of the ISA spec.

We discussed having the more general case of VLMAX being the bound,
but consensus was that having bound be a function of VLEN (<=65536)
was simpler to specify and had no great effect on range of supported
systems.

The extension to add independent control of data input size of
vrgather, proposed in #655, was briefly discussed, but this will not
be included in v1.0.

#651 expanding tail-agnostic to allow result values (masks only, or data)

The discussion was around expanding the set of allowable tail-agnostic
values to include the results of the computation.

The consensus was to expand this for mask register writes (except
loads), where only tail-agnostic behavior is required.

But support was not as clear for data register writes, where
tail-undisturbed behavior must be supported and where FP operations
require masking off exception flags even for tail-agnostic.

PoR is to expand mask register writes to allow results to be written
in tail, while continuing discussion on further relaxing for data
register writes.

#457 Ordering in vector AMOs

Current vector AMOs have no facility to order writes to the same
address, whereas indexed stores have an ordered option.

Discussion was on proposal to tie address-based ordering to the wd
(write result data) bit. One concern was that this seemed to hamper
some cases, including where software wanted the results but knew
addresses were disjoint. Providing ordering only on same address
would likely require slow implementation on out-of-order machine where
addresses can be produced out of order for different element groups.

Decision was to maintain PoR and consider post-v1.0 ways to support
ordered vector AMOs.


Next Vector TG Meeting, Friday March 19

Krste Asanovic
 

There are a few issues to discuss, so we’ll meet in the regular time slot on the calendar,
Krste


cancel Mar 12 Vector TG meeting

Krste Asanovic
 

I'm cancelling meeting again, as I still have not been able to clean
spec. I realize it will be more efficient for folks to wait for a
clean version for a complete read through. Few issues are being
reported/found, so I do not anticipate any substantive change.

One realization on issue #640 is that VLEN limit (<=64Kb) has to be
part of ISA spec, not just profile, to allow backwards compatibility.
Details on github issue.

One update is that RIOS Lab has agreed to help with architecture tests
and the SAIL model - thank you, RIOS!

Krste


cancel next Vector TG meeting, Friday March 5

Krste Asanovic
 

I'm still working through spec cleanup.

The list and github has been quiet, and I have no new issues to raise,
so I suggest we cancel this meeting and push out for a week.

Krste


Vector Task Group meeting minutes for 2021/2/19

Krste Asanovic
 

Date: 2021/02/19
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~23
Current issues on github: https://github.com/riscv/riscv-v-spec

# Next Meeting/Freezing

The schedule is to meet again in two weeks (Friday March 5). The plan
is to have all pending updates and cleanups in spec by that date, to
be able to agree to freeze and move forward into public review (v1.0),
which should happen soon after this meeting. Please continue to send
PRs for any small typos and clarifications, and use mailing list for
larger issues.

Issues discussed

#640 Bound on VLMAX

The major issue raised was that software would otherwise have to cope
with indices that might not fit in 16b. The group agreed that
profiles and/or platform specs can set the upper bound, with a current
recommendation that all profiles limit VLMAX to 64K elements
(VLEN=64Kib, or 8K bytes per vector register). The current ISA spec can
support larger VLMAX already, but adding vrgatherei32 instruction
would be a useful addition (post-v1.0) if architectural vector
regfiles >256KiB become common.

It was also discussed that a privileged setting will be desired to
modulate visible VLEN to support thread migration, or just different
application vector profiles with different VLMAX in general.


Re: Zfinx + Vector

Tariq Kurd
 

Thanks Krste, I’ve put exactly that I the spec.

 

Tariq

 

From: tech-vector-ext@... [mailto:tech-vector-ext@...] On Behalf Of Krste Asanovic
Sent: 18 February 2021 19:09
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] Zfinx + Vector

 

If you check over the vector instruciton listing table It’s all the instructions in funct3=OPFVF with an F in the operand column. Most of these are missing.

 

Krste



On Feb 18, 2021, at 10:44 AM, Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

 

Hi everyone,

 

I’ve updated the Zfinx spec to show which V-extension instructions are affected.

 

 

Please review the list, and tell me of any impact on the vector spec which I’ve overlooked.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK       

 

<image001.png>    http://www.huawei.com

<image002.jpg>

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Vector task group meeting, Friday Feb 19

Krste Asanovic
 

We’ll meet today in usual slot, details on Google calendar

Agenda is to discuss any issues found while reading over the v0.10 spec.
List and GitHub has been quite quiet, so this might be a short meeting.

Krste


Re: Zfinx + Vector

Krste Asanovic
 

If you check over the vector instruciton listing table It’s all the instructions in funct3=OPFVF with an F in the operand column. Most of these are missing.

Krste

On Feb 18, 2021, at 10:44 AM, Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,
 
I’ve updated the Zfinx spec to show which V-extension instructions are affected.
 
 
Please review the list, and tell me of any impact on the vector spec which I’ve overlooked.
 
Thanks
 
Tariq
 
Tariq Kurd
Processor Design I RISC-V Cores, Bristol
Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK       
 
<image001.png>    http://www.huawei.com
<image002.jpg>
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !
本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
 


Zfinx + Vector

Tariq Kurd
 

Hi everyone,

 

I’ve updated the Zfinx spec to show which V-extension instructions are affected.

 

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc#vector

 

Please review the list, and tell me of any impact on the vector spec which I’ve overlooked.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

61 - 80 of 651