Date   

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



Re: Configuring qemu for Vector Extension

Jim Wilson
 

On Sat, Sep 18, 2021 at 3:57 PM Mick Thomas Lim <mickthomaslim@...> wrote:
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

I don't do LLVM work, and can't offer any suggestions there.
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.

You should be willing to accept whatever version you can get instead of asking for v1p0, and be willing to rewrite your code when v1p0 comes out.  If you really do need v1p0, then you probably should wait 6 months until there is an actual v1p0 draft, and free toolchain, simulator, kernel, library, etc support for it.

Jim
 


Re: Configuring qemu for Vector Extension

Mick Thomas Lim
 

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

Nick Knight
 

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

Mick Thomas Lim
 

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 (吴伟)


Vector spec v1.0-rc2

Krste Asanovic
 

I've finally finished an extensive pass over the whole spec, and
believe it should be ready for public review but given that it's late
on a Friday, I would like to give at least one more sleep cycle before
releasing.

So, last call to make last-minute suggestions on this version I've
tagged as v1.0-rc2 before I pass final version to the team to release
tomorrow (that will be tagged v1.0).

Krste


Re: vwredsum

Krste Asanovic
 

Added explicit statement to spec for this case. There was a wrap-around
statement for single-width but not for widening reductions.

Krste

On Fri, 17 Sep 2021 14:22:07 +1200, "Bruce Hoult" <bruce@hoult.org> said:
| As a 2*SEW scalar from element 0 of vs1 is added to the sum of the various SEW
| elements in vs2, even a vector of length 1 can cause overflow.

| On Fri, Sep 17, 2021 at 12:43 PM Earl Killian <earl.killian@arilinc.com>
| wrote:

| If the vector operand to an integer vwredsum is long enough, 2*SEW will
| not be large enough to contain the result. I would interpret the spec to
| suggest that the low 2*SEW bits are written to the destination (there is
| not mention of saturation), but it seems like it deserves a mention, if
| only to encourage software to think about precision and vector length.

|


Re: vwredsum

Bruce Hoult
 

As a 2*SEW scalar from element 0 of vs1 is added to the sum of the various SEW elements in vs2, even a vector of length 1 can cause overflow.


On Fri, Sep 17, 2021 at 12:43 PM Earl Killian <earl.killian@...> wrote:
If the vector operand to an integer vwredsum is long enough, 2*SEW will not be large enough to contain the result. I would interpret the spec to suggest that the low 2*SEW bits are written to the destination (there is not mention of saturation), but it seems like it deserves a mention, if only to encourage software to think about precision and vector length.







vwredsum

Earl Killian
 

If the vector operand to an integer vwredsum is long enough, 2*SEW will not be large enough to contain the result. I would interpret the spec to suggest that the low 2*SEW bits are written to the destination (there is not mention of saturation), but it seems like it deserves a mention, if only to encourage software to think about precision and vector length.


Re: Configuring qemu for Vector Extension

Wei Wu (吴伟)
 

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@hoult.org> 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@gmail.com> 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@sifive.com> wrote:

On Sun, Sep 12, 2021 at 5:21 PM Mick Thomas Lim <mickthomaslim@gmail.com> 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 (吴伟)

61 - 80 of 761