Date   

Re: RISC-V Vector Extension post-public review updates

Krste Asanovic
 

On Mon, 15 Nov 2021 13:29:58 -0800, Guy Lemieux <guy.lemieux@gmail.com> said:
| We do have a choice of:

| 1) Mandate all implementations raise an illegal exception in this
| case.  This is my preferred route, as this would be a minor errata for
| existing implementations (doesn't affect software), and we would not reuse
| this state/encoding for other purposes.

| 2) Allow either correct execution or illegal exception (as with
| misaligned). 

| 3) Consider "reserved", implying implementations that support it are
| non-conforming unless we later go with 2).

| I don’t have a strong opinion, but I prefer a route that allows us to recover those instruction encodings — they seem to be getting scarce hence represent
| value. You said there were already requests for extra instructions — would this space be usef for any of them (or other as-yet-unforeeen instructions)?

| Does (3) give us the best route to reuse the encodings in the future? I’m a bit confused about the permanence of (1), and I don’t like the possibility
| software fragmentation that will arise from (2).

| Guy

The problem with this encoding space is that in some cases (i.e.,
vector indexed stores) the reserved encoding is actually only for some
combination of vtype control state + instruction bits, or in the
others it is low-quality space, e.g., where the source vector register
specifiers overlap.

So, I would assume 1) would be permanent.

As a general comment, folks seem to overweight the long-term value of
awkward corners of the encoding space, versus the short/medium-term
benefits of having clean and simple encoding. More mature
architectures tend to add cleaner extended encodings (prefix
bytes/words) rather than ramming substantial additions into awkward
unused corners.

Krste


Re: RISC-V Vector Extension post-public review updates

Guy Lemieux
 

That’s great news, thanks Krste!

The current specification allows some instructions to have two vector
source operands read from the same vector register but with different
EEW. 

(cue folks furiously trying to construct one...)

haha i tried but can’t think of a use case !!

We do have a choice of:

1) Mandate all implementations raise an illegal exception in this
case.  This is my preferred route, as this would be a minor errata for
existing implementations (doesn't affect software), and we would not reuse
this state/encoding for other purposes.

2) Allow either correct execution or illegal exception (as with
misaligned). 

3) Consider "reserved", implying implementations that support it are
non-conforming unless we later go with 2).

I don’t have a strong opinion, but I prefer a route that allows us to recover those instruction encodings — they seem to be getting scarce hence represent value. You said there were already requests for extra instructions — would this space be usef for any of them (or other as-yet-unforeeen instructions)?

Does (3) give us the best route to reuse the encodings in the future? I’m a bit confused about the permanence of (1), and I don’t like the possibility software fragmentation that will arise from (2).

Guy


RISC-V Vector Extension post-public review updates

Krste Asanovic
 

Apart from requests for more instructions, which can be handled with
later extensions, there were no real substantive updates.

I did notice one issue at end of public review, however.

The current specification allows some instructions to have two vector
source operands read from the same vector register but with different
EEW. For example, a vector indexed store with the index vector and
data vector overlapping, but different EEW. Or a widening vector add
(vwadd.wv) where the two vector sources overlap but have different
EEW. This complicates implementations that internally restripe the
vector data (e.g., internal SLEN), and does not have a valid software
use (cue folks furiously trying to construct one...).

The proposal is to allow implementations to raise an illegal
instruction exception in this case. I believe this is an important
and necessary change to accomodate internal striping. In practice,
this change has no impact on software.

We do have a choice of:

1) Mandate all implementations raise an illegal exception in this
case. This is my preferred route, as this would be a minor errata for
existing implementations (doesn't affect software), and we would not reuse
this state/encoding for other purposes.

2) Allow either correct execution or illegal exception (as with
misaligned).

3) Consider "reserved", implying implementations that support it are
non-conforming unless we later go with 2).

I'm assuming we're going to push to ratify 1) unless I hear strong objections.

Krste


Re: reliably set vtype.vill

Tim Newsome
 

As usual, Krste is completely right. This was a matter of OpenOCD not doing what I thought it was doing. Thanks for your help.

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Bill Huffman
 

Still could be worth a non-normative comment saying something like “even though there may not be a separate bit for vill, if the source register of a vsetvl instruction has bit XLEN-1 set, vtype will be set to illegal.”

 

     Bill

 

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Monday, November 1, 2021 2:09 PM
To: Krste Asanovic <krste@...>
Cc: Tim Newsome <tim@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] reliably set vtype.vill

 

EXTERNAL MAIL

(newType >> 8) != 0;

 

This last clause in spike code would seem to catch the case in question ??

 

Krste



On Nov 1, 2021, at 11:03 AM, Krste Asanovic via lists.riscv.org <krste=sifive.com@...> wrote:

 

From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste



On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@...> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste


On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim

 





 


Re: reliably set vtype.vill

Krste Asanovic
 


(newType >> 8) != 0;

This last clause in spike code would seem to catch the case in question ??

Krste

On Nov 1, 2021, at 11:03 AM, Krste Asanovic via lists.riscv.org <krste=sifive.com@...> wrote:

From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste


On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@...> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim







Re: reliably set vtype.vill

Bill Huffman
 

I think that deserves at least a non-normative comment. I think many won't intuit from what's below that a bit that's otherwise stated doesn't need to exist will be "set" that way.

But I agree setting it the way you said is the way it should be done.

Bill

-----Original Message-----
From: tech-vector-ext@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Krste Asanovic
Sent: Monday, November 1, 2021 2:04 PM
To: Tim Newsome <tim@sifive.com>
Cc: tech-vector-ext@lists.riscv.org
Subject: Re: [RISC-V] [tech-vector-ext] reliably set vtype.vill

EXTERNAL MAIL


From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste


On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@sifive.com> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@sifive.com> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@sifive.com> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Alex Solomatnikov
 

vsetvli x1, x0, e8, m8
vsetvli x0, x0, e16, m8

Alex

On Mon, Nov 1, 2021 at 9:46 AM Tim Newsome <tim@...> wrote:
I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Krste Asanovic
 

From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste

On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@sifive.com> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@sifive.com> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@sifive.com> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Tim Newsome
 

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Krste Asanovic
 

Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


reliably set vtype.vill

Tim Newsome
 

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: Basic options for chaining vector loads?

Andrew Waterman
 

Historically, vector machines have employed a wide variety of strategies here.  Simply not executing past a vector memory access until exception checks have been performed is the simplest thing to do.  Standard speculative execution and rollback techniques (e.g. ROB/renaming) have also been used.  And there are a variety of microarchitectural hacks in between those extremes that I'll let others comment on if they wish.

Other vector ISAs haven't mandated precise exceptions at all, which makes this problem trivial, but RVV hasn't standardized this option, and it's inappropriate in many circumstances anyway.

(PS. The fault-only-first loads weren't designed to ease chaining; they were designed to support the vectorization of loops whose trip count isn't known at loop entry.)


On Wed, Oct 27, 2021 at 7:31 AM Arjan Bink <Arjan.Bink@...> wrote:

Hello all,

Could somebody please comment on the basic options related to chaining vector loads? It is easy to see how arithmetic vector instructions can be chained together. However, if a vector load is followed by an arithmetic instruction that depends on it (e.g. as shown in the below example), then chaining is not as easy as the vector load could cause a synchronous exception on any of its elements. If we would use chaining anyway, then instructions following such a vector load might have to be undone (or prevented from updating the register file) maybe as late as during an exception on the last element of such a vector load (which would be costly/complex) if we want to support precise exceptions.

VLD  v1, r1
VLD  v2, r2
VMUL v3, v1, v2
VST  v3, r3

I see some basic strategies:

A) Unroll above code such that the vector loads and arithmetic instructions become indepedent of each other (then a vector load can execute in parallel with a preceding arithmetic instructions that do not source the vector register updated by the vector load)

B) Make the bus interface used by the vector load really wide such that not being able to chain it hurts less (fewer cycles lost). This might work well for unit stride loads, but not really well for vector indexed (scatter gather) loads.

C) Use fault-only-first vector loads. Are such loads intended to allow for easier chaining (as it will be known early if a load will cause a fault or not)?

D) Somehow predict/compute early on whether exceptions can potentially happen during any element of a vector load/store. This seems not at all practical in the context of vector indexed loads/stored, but is maybe feasible for unit stride vector loads/stores.

Any good other alternatives that I am missing here or pros and cons that are worth mentioning?

Best regards,
Arjan


Basic options for chaining vector loads?

Arjan Bink
 

Hello all,

Could somebody please comment on the basic options related to chaining vector loads? It is easy to see how arithmetic vector instructions can be chained together. However, if a vector load is followed by an arithmetic instruction that depends on it (e.g. as shown in the below example), then chaining is not as easy as the vector load could cause a synchronous exception on any of its elements. If we would use chaining anyway, then instructions following such a vector load might have to be undone (or prevented from updating the register file) maybe as late as during an exception on the last element of such a vector load (which would be costly/complex) if we want to support precise exceptions.

VLD  v1, r1
VLD  v2, r2
VMUL v3, v1, v2
VST  v3, r3

I see some basic strategies:

A) Unroll above code such that the vector loads and arithmetic instructions become indepedent of each other (then a vector load can execute in parallel with a preceding arithmetic instructions that do not source the vector register updated by the vector load)

B) Make the bus interface used by the vector load really wide such that not being able to chain it hurts less (fewer cycles lost). This might work well for unit stride loads, but not really well for vector indexed (scatter gather) loads.

C) Use fault-only-first vector loads. Are such loads intended to allow for easier chaining (as it will be known early if a load will cause a fault or not)?

D) Somehow predict/compute early on whether exceptions can potentially happen during any element of a vector load/store. This seems not at all practical in the context of vector indexed loads/stored, but is maybe feasible for unit stride vector loads/stores.

Any good other alternatives that I am missing here or pros and cons that are worth mentioning?

Best regards,
Arjan


Re: Is it safe to extend LMUL's maximum value based on current rc2 version?

Bruce Hoult
 

On Tue, Oct 5, 2021 at 11:30 PM Feng Chuang <Chuang_Feng@...> wrote:
hi  Krste and all friends,

Per my understanding, if I extend the vector architecture register number (to be larger than 32) and extend maximum LMUL value to be larger than 8, current vector extension (v1.0) still works fine in terms of completeness and correctness, given mask value can be read from multiple continuous vector registers and even with a mask register specifier as indicated in the spec note for future extension.

I'm trying to understand the reason for this.

Do you need more than 32 register variables for some algorithm? (of course unrolling a loop can use arbitrary numbers of registers) How will you address them? WIth new longer instruction formats?

If you're addressing more registers only by making LMUL bigger, what advantage does that have over simply making VLEN bigger?
 


Re: Is it safe to extend LMUL's maximum value based on current rc2 version?

David Horner
 

Thank you for this very important consideration.

On 2021-10-05 6:29 a.m., Feng Chuang wrote:
hi  Krste and all friends,

Per my understanding, if I extend the vector architecture register number (to be larger than 32) and extend maximum LMUL value to be larger than 8, current vector extension (v1.0) still works fine in terms of completeness and correctness, given mask value can be read from multiple continuous vector registers and even with a mask register specifier as indicated in the spec note for future extension.
Yes. The expectation is that many of the current constraints will be relaxed in future versions.
I'm thinking in in this way for our future design thus wondering whether anyone already on this way and any experience can be shared especially on compatibility and tool chain related work.
It is here that I most appreciate your interest. I have not followed the rvv doc and intrinsic efforts as specifically for artificial/structural assumptions on constrains as I now belive I should have. given the intent to relaqx certain of these constraints.
I tried searching related discussion but couldn't found obvious discussion on LMUL > 8 (maybe that was in too early stages and hadn't been archived into this workgroup).

There was extensive discussion on changing masks structure from being tied to LMUL and ELEN to being an ordinal value with the bits for any element [regardless of size]always in the same place.

Decoupling mask in this way allows spanning more than 8 registers in a register set.LMUL's

On the hithuib site there are many issues flagged as post v1.0. Some of these relate directly to your desire to extend rvv.

One such suggestion was to relax the LMUL restriction for widening functions so that LMUL=8 inputs would effect ELMUL of 16.

This modest extension is still on the books for consideration.

But in general rc2 has "whole new world" possibilities that in my opinion could drastically benefit future implementations, especially the minimal configurations that could have , as an example, full utilization of the rvv register file for move word operations.


Thanks in advance! Appreciated if any sharing/help. 


Is it safe to extend LMUL's maximum value based on current rc2 version?

Feng Chuang
 

hi  Krste and all friends,

Per my understanding, if I extend the vector architecture register number (to be larger than 32) and extend maximum LMUL value to be larger than 8, current vector extension (v1.0) still works fine in terms of completeness and correctness, given mask value can be read from multiple continuous vector registers and even with a mask register specifier as indicated in the spec note for future extension.
I'm thinking in in this way for our future design thus wondering whether anyone already on this way and any experience can be shared especially on compatibility and tool chain related work. 
I tried searching related discussion but couldn't found obvious discussion on LMUL > 8 (maybe that was in too early stages and hadn't been archived into this workgroup). 

Thanks in advance! Appreciated if any sharing/help. 


Re: Configuring qemu for Vector Extension

Tony Cole
 

Hi Mick,

 

This is what I do for 32-bit RISC-V Vector on ubuntu1804, admittedly it took me a long time to find a combination that worked and I had help to get the correct switches:

 

 

Risc-V Vector 32-bit v0p10 Compile/Link/Run Command Lines and Switches:

 

## Tools Required

 

Compiler used:

https://buildbot.embecosm.com/job/riscv32-clang-ubuntu1804/54/artifact/riscv32-embecosm-clang-ubuntu1804-20210509.tar.gz

 

Linker used, this was a special build for me by Embercosm with a full library build (– thank you Embercosm):

https://buildbot.embecosm.com/job/riscv32-gcc-ubuntu1804/60/artifact/riscv32-embecosm-gcc-ubuntu1804-20210523-defaultnewlib.tar.gz

 

QEMU used was Git cloned from (at the time) the latest RISC-V Vector QEMU branch from SiFive:

https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7-fix

Follow the building instructions in the README.rst.

 

## Compile/Link/Run Switches

 

LLVM Clang Compile only:

/data/toolchains/riscv/riscv32-embecosm-clang-ubuntu1804-20210509/bin/riscv32-unknown-elf-cc -ffunction-sections -fdata-sections -fmacro-backtrace-limit=0 -march=rv32imafcv0p10 -mabi=ilp32f -menable-experimental-extensions -Xclang -target-feature -Xclang -experimental-zvamo -Xclang -target-feature -Xclang -experimental-zvlsseg -O2 -flax-vector-conversions -o filename.obj -c filename.c

 

GCC Link:

/data/tony/Toolchains/riscv32-embecosm-gcc-ubuntu1804-20210523-defaultnewlib/bin/riscv32-unknown-elf-gcc -ffunction-sections -fdata-sections -march=rv32imafc -mabi=ilp32f -Wl,--gc-sections -o filename.out filename.obj

 

QEMU Execute:

/data/tony/sifive/qemu/build/qemu-riscv32 -s 2048M -p 131072 -cpu rv32,x-v=true filename.out

 

 

I use the GCC Linker to get printf float support in the libraries. If you don’t require library float support, then I think you may be able to just compile and link using Clang.

 

 

Try it for 32-bits first, then change/modify for 64-bits (I’ve not tried 64-bits – good luck!). Let us know if it works or not (and what you did so others can benefit).

 

 

I hope this helps,

 

 

Tony

 

 

From: tech-vector-ext@... [mailto:tech-vector-ext@...] On Behalf Of Mick Thomas Lim
Sent: 19 September 2021 01:01
To: Nick Knight <nick.knight@...>
Cc: Jim Wilson <jimw@...>; tech-vector-ext@...; Tony Cole <tony.cole@...>
Subject: Re: [RISC-V] [tech-vector-ext] Configuring qemu for Vector Extension

 

I see.

 

I'm ashamed to admit, but I am now really lost between all the permutations of Vector ext. revisions and toolchain versions that I've attempted without success.

 

At this point, I'd just like to establish a known-good setup that can successfully run these examples (or even just rvv_saxpy.c): https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/master/examples

 

A prescribed list of what specific versions/branches of qemu, gcc/clang, etc. I should pull down; as well as specific build and run command parameters would be a lot of help.

 

Thanks,

Mick

 

On Sat, Sep 18, 2021 at 4:02 PM Nick Knight <nick.knight@...> wrote:

V-extension version 1.0 hasn't been frozen yet. Its second release candidate was posted just yesterday:

 

 

I wouldn't expect toolchain support for "v1p0" until (some time) after the actual spec has frozen.

 

The latest frozen version is 0.10. If you're able to get that working, then you're on the cutting edge as far as I'm concerned.

 

Best,

Nick

 

On Sat, Sep 18, 2021 at 3:57 PM Mick Thomas Lim <mickthomaslim@...> wrote:

Hello Jim,

Where could I find the last clang build for v1p0?

I've followed the instructions laid out here, which pulls from upstream LLVM: https://github.com/sifive/riscv-llvm

But this e-mail appears to indicate that only v0p10 is supported so far: https://lists.riscv.org/g/tech-vector-ext/message/595

 

Alternatively, how is everyone running v1p0 programs on v1.0 qemu?

We'd like to adhere as closely to the latest Vector ext. revision as possible.

 

Also, thanks everyone for the clarifying info on the current state of development!

 

-Mick

 

On Wed, Sep 15, 2021 at 6:35 AM Wei Wu (吴伟) <lazyparser@...> wrote:

HI Bruce,

The all-in-one QEMU and GNU toolchain will support the latest version
of Vector spec. For the V extension v0.7.1, we are planning to run
docker containers on Allwinner Nezha board directly, so that RISC-V
Lab users can run their codes directly.

On Wed, Sep 15, 2021 at 11:30 AM Bruce Hoult <bruce@...> wrote:
>
> Do you support RVV 0.7.1 as well as tracking 1.0?
>
> RVV 0.7.1 is the only version available in real mass-produced hardware at the moment, and probably for the next 12 to 18 months at a guess. I myself own a board with RVV 0.7.1 support (Allwinner Nezha). and Sipeed are promising a cheap board with it soon (maybe Pine64 also, but we haven't heard any recent confirmation of their plans announced at the start of the year)
>
> 0.7.1 is incompatible with 1.0 in a couple of important ways -- mostly subelement operations were replaced by fractional LMUL, loads and stores became pure bit transfers with any necessary sign or zero extension done register-to-register afterwards, and changes to policy options for tail and masked off elements -- but it's still a very nice, very practical length-agnostic Vector instruction set, up there with SVE 1/2 and RVV 1.0.
>
> It's going to be some time before most people have access to either SVE or RVV 1.0.
>
> On Tue, Sep 14, 2021 at 5:52 PM Wei Wu (吴伟) <lazyparser@...> wrote:
>>
>> Hi Mick,
>>
>> As Jim said, you may need the right toolchain and right qemu for the
>> version you want, which is not an easy task.
>>
>> BTW, the PLCT Lab is working on setting an all-in-one developer
>> environment for unratified extensions, including Vector.
>>
>> Currently QEMU and GNU Toolchain are available. Feel free to try it out:
>>
>> We cherry-pick and rebase the B/K/P/V patches and merge them into one branch.
>>
>> QEMU:
>> https://github.com/plctlab/plct-qemu/tree/new-machine-dev
>>
>> gcc:
>> https://github.com/pz9115/riscv-gcc/tree/riscv-gcc-experimenal-v
>>
>> binutils:
>> https://github.com/pz9115/riscv-binutils-gdb/tree/riscv-binutils-experimental-v
>>
>> It is still under development, and I hope that the PLCT Lab might be
>> able to provide several online QEMU VMs for public access and
>> experiment in 2 weeks.
>>
>> On Tue, Sep 14, 2021 at 12:06 AM Jim Wilson <jimw@...> wrote:
>> >
>> > On Sun, Sep 12, 2021 at 5:21 PM Mick Thomas Lim <mickthomaslim@...> wrote:
>> >>
>> >> A "Hello World" program compiled with riscv64-unknown-linux-gnu-gcc does work.
>> >> But we aren't seeing expected behavior when running the simple rvv_vadd.c program described here:
>> >> https://lists.riscv.org/g/tech-vector-ext/message/364
>> >
>> >
>> > There are many thousands of different incompatible draft versions of the vector spec.  If you don't have exactly matching versions of the compiler and qemu and libraries, it isn't going to work.  Unfortunately, it will continue to be difficult to work with the vector spec until they stop changing it in incompatible ways.
>> >
>> > The current vector work incidentally is in clang not gcc.  The gcc support may not be compatible with anything else as it hasn't been properly updated.
>> >
>> >> This is the qemu run command we're using for buildroot:
>> >> qemu-system-riscv64 -cpu rv64,x-v=true,vlen=256,elen=64,vext_spec=v0.7.1    -M virt -nographic    -bios output/images/fw_jump.elf    -kernel output/images/Image    -append "root=/dev/vda ro"    -drive file=output/images/rootfs.ext2,format=raw,id=hd0    -device virtio-blk-device,drive=hd0    -netdev user,id=net0 -device virtio-net-device,netdev=net0
>> >
>> >
>> > The v0.7.1 draft has been obsolete for about 2 years now.  That won't be useful.  Unless maybe you have Alibaba compilers as this is what Alibaba implemented in their SoCs.  Otherwise, you are better off with a v0.9x or v1.0 qemu.  I would expect to find patches for that on the qemu mailing list.  But another person pointed to a branch in a SiFive github tree that may work for you.
>> >
>> > Jim
>> >
>> >
>>
>>
>>
>> --
>> Best wishes,
>> Wei Wu (吴伟)
>>
>>
>>
>>
>>


--
Best wishes,
Wei Wu (吴伟)


Re: Configuring qemu for Vector Extension

Wei Wu (吴伟)
 

On Sun, Sep 19, 2021 at 11:39 AM Jim Wilson <jimw@sifive.com> wrote:

On Sat, Sep 18, 2021 at 3:57 PM Mick Thomas Lim <mickthomaslim@gmail.com> wrote:
Alternatively, how is everyone running v1p0 programs on v1.0 qemu?
We'd like to adhere as closely to the latest Vector ext. revision as possible.
In general, I'd say that if you don't have a half dozen people doing assembler, compiler, simulator, kernel, library, etc work, then you probably won't be able to create your own V environment. Unfortunately SiFive doesn't have a free V distribution anymore. And no, the freedom-u-sdk V support isn't useful. I would suggest that PLCT is your best bet. See Wei Wu's message pointing your at binutils, gcc, and qemu trees. Except Wei Wu pointed at gcc and the gcc V support is known to have problems, so is not a good choice. So there is probably no free good V environment available at this time.
That's true. :)

Providing full support for Vector extension is already on the todo-list of
CAS/PLCT Lab.

Vector extension is one of the extensions that are included in an
all-in-one developer environment project in PLCT Lab. If one extension
is not ready, we will implement it first. And given that the v1.0 tag has just
been tagged[1], it is a good time to start :)

There was a working branch for V-ext in riscv-gnu-toolchain repo
maintained by SiFive staff, and unfortunately SiFive does not have enough
GCC developers for maintaining it to keep it up to date with the
latest draft. I've talked with Kito who is working on Vector impl for
GNU toolchain, and he welcomes us working on it. The PLCT Lab has set
a few CI/Testing jobs watching the public V-ext branch already, and plans to
start the upgrading work after the initial all-in-one environment for
developers release.

A developer from Alibaba/T-Head is working on V-ext on GCC. Although
T-Head is working on the v0.7.1 draft version, the developer from
T-Head has contributed a few patches for the latest drafts. I'm optimistic
that at least one SiFive staff and one T-Head staff will contribute in
their spare time.

A more ambitious plan is to implement an open source RISC-V core with
B/K/P/V-ext enabled, using Chisel as the impl language. It is only an
idea in my head now, and currently no staff in PLCT Lab is working on it
(a few interns may start the project next month). I'd like to provide help on
software support if there is another team willing to work on it.

[1] https://github.com/riscv/riscv-v-spec/releases/tag/v1.0

--
Best wishes,
Wei Wu (吴伟)


Vector 1.0 ready for public review

Krste Asanovic
 

I’ve made a frozen release of version 1.0 ready for public review.

The release is tagged: 


and I’ve attached pdf below.

The main repo has now advanced to v1.1-draft for updates post public review.

Thanks all for all the hard work and contributions over the many years this took,

Krste


81 - 100 of 790