Date   

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


Re: Configuring qemu for Vector Extension

Bruce Hoult
 

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






Specify byte index/offset for Strided/Indexed instructions. Minor document improvement RISC-V "V" Vector Extension Version 1.0-rc1-20210608

Tony Cole
 

It might be worth updating sections:

7.5 Vector Strided Instructions
7.6 Vector Indexed Instructions

with the address calculations to specify the stride offsets and indexs and byte sized, rather than element sized.

I know this is specified in section 7.2 (Vector Load/Store Addressing Modes), but it is useful to have it where the instructions are specified as well (as I wasted time finding it!)


Clarification of Fractional LMUL requirements, and the storage/derivation of ELEN/SEWLMUL1MAX values

Krste Asanovic
 

Thanks for the suggestions.

I tried to clean up and clarify this section:

https://github.com/riscv/riscv-v-spec/commit/3cc98373f954df996c2d7973ef0fc38bc866f620

Krste

On Wed, 8 Sep 2021 15:25:39 -0700, "Gregory Kielian via lists.riscv.org" <gkielian=google.com@lists.riscv.org> said:
| Hi,
| Re-reading section 3.3.2 in the documentation (link), would like to propose adding goal, constraints, steps for implementing Fraction LMUL

| I think adding these would really help clarify both the VFLMUL idea and implementation. I've been having extensive discussions around this,
| re-reading this section a bunch, and thinking it would probably be good to add additional lines to the vspec.adoc to clarify the idea.

| Sharing my tentative understanding below (and some questions on ELEN and SEWLMUL1MAX), derived mainly from looking at the spike lmul checks and
| 3.3.2, curious as well if this captures the main intent of the fractional-lmul or there are aspects which are missing or equations require
| adjustment:

| • Goal clarification:

| □ Fractional LMUL allows the result of widening operations to be definitively contained within a single vector register.

| □ The advantage this provides seems (at least) two-fold

| ☆ Any register is usable for widening with fractional LMULs (opposed to integer LMUL can be used only for registers evenly divisible
| by the LMUL, e.g. v0, v8, v16, v24 for LMUL = 8).

| ☆ Related to above, less registers are locked down by the application of widening, reducing register availability bottlenecks and the
| needed number of stores/loads to-and-from memory.

| □ In order to ensure that the result of widening operations can be contained in a single register, there are certain constraints (see
| below)
| • Constraints:

| □ SEW <= ELEN*VFLMUL

| ☆ Example 1: ELEN = e32, VFLMUL= ⅛

| ○ SEW <= ELEN*VLMUL = 4, VFLMUL ⅛ illegal for ELEN e32

| ☆ Example 2: ELEN e32, VFLMUL = ¼

| ○ SEW <= ELEN*VFLMUL = 8, therefore SEW must be e8

| ☆ Example 2: ELEN e32, VFLMUL = ½ 

| ○ SEW <= ELEN*VLMUL = 16, therefore SEW must either e8, e16

| □ Note: For architectures where ELEN > SEWLMUL1MAX, one would go throught the same exercise as above but with s/ELEN/SEWLMUL1MAX.

| • Where to store/how-to-derive of ELEN and/or SEWLMUL1MAX:

| □ ELEN/SEWLMUL1MAX are not stored in CSR’s, ELEN may be derived from the extension:

| ☆ Example: ELEN = e32 for ZVE32x

| □ SEWLMUL1MAX storage/derivation questions (this particular one is unclear to me):

| ☆ If ELEN > SEWLMUL1MAX, how would one derive SEWLMUL1MAX from the ELEN?

| ☆ Where (e.g. any CSR) would the SEWLMUL1MAX be stored?

| ☆ Would this be derived from knowing the specific extension and perhaps the Vlenb and held in a special architecture specific
| register?

| Suggested edits for discussion: 

| • Adding SEW equation, possibly in mathematical notation, to clarify the policy

| • Adding some examples to clarify the policy

| • Adding goal/intent and advantages of using fractional-lmul vs lmul and vice versa

| Would be happy to contribute pull requests after confirming whether this understanding is correct, and clarifying questions about the
| SEWLMUL1MAX/ELEN derivation/storage.

| All the best,

| Gregory

|


Re: Configuring qemu for Vector Extension

Wei Wu (吴伟)
 

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


回复:[RISC-V] [tech-vector-ext] Configuring qemu for Vector Extension

LIU Zhiwei
 

Hi Mick,

The vector 0.7.1 version has been implemented in T-Head Xuantie c910v CPU and AllWinner D1 Soc.  If that's what you want or If you want to use the QEMU upstream currently, I can give you some advice.

The toolchian binary you can download from the link:

You can compile your program with -march rv64gcv -mabi=lp64dv.

The programming intrinsic is very similiar to the upstrem gcc and please see the attachment.

Thanks,
Zhiwei

------------------------------------------------------------------
发件人:Mick Thomas Lim <mickthomaslim@...>
发送时间:2021年9月13日(星期一) 08:24
收件人:tech-vector-ext <tech-vector-ext@...>
主 题:[RISC-V] [tech-vector-ext] Configuring qemu for Vector Extension

Does a known-good guide exist for building riscv64 qemu to be able to run Vector instructions?

From the main qemu repo, we are to build the riscv64-softmmu target and run the 64-bit Buildroot Image, as described here:

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:

For example: vl = vsetvl_e32m2 (n) seems to return 0.

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

Assistance would much appreciated!

Sincerely,
Mick


Re: Configuring qemu for Vector Extension

Jim Wilson
 

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:

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


Re: Configuring qemu for Vector Extension

Tony Cole
 

Hi Mick,

 

I use the RISC-V Vector QEMU branch from SiFive (for 32-bit, don’t know about 64-bit support though):

 

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

 

Also, there may be a later version.

 

 

Follow the building instructions in the README.rst.

 

 

Hope this helps.

 

 

Tony

 

 

From: tech-vector-ext@... [mailto:tech-vector-ext@...] On Behalf Of Mick Thomas Lim
Sent: 13 September 2021 01:21
To: tech-vector-ext@...
Subject: [RISC-V] [tech-vector-ext] Configuring qemu for Vector Extension

 

Does a known-good guide exist for building riscv64 qemu to be able to run Vector instructions?

 

From the main qemu repo, we are to build the riscv64-softmmu target and run the 64-bit Buildroot Image, as described here:

 

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:

 

For example: vl = vsetvl_e32m2 (n) seems to return 0.

 

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

 

Assistance would much appreciated!

 

Sincerely,

Mick


Configuring qemu for Vector Extension

Mick Thomas Lim
 

Does a known-good guide exist for building riscv64 qemu to be able to run Vector instructions?

From the main qemu repo, we are to build the riscv64-softmmu target and run the 64-bit Buildroot Image, as described here:

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:

For example: vl = vsetvl_e32m2 (n) seems to return 0.

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

Assistance would much appreciated!

Sincerely,
Mick


Clarification of Fractional LMUL requirements, and the storage/derivation of ELEN/SEWLMUL1MAX values

Gregory Kielian
 

Hi,


Re-reading section 3.3.2 in the documentation (link), would like to propose adding goal, constraints, steps for implementing Fraction LMUL


I think adding these would really help clarify both the VFLMUL idea and implementation. I've been having extensive discussions around this, re-reading this section a bunch, and thinking it would probably be good to add additional lines to the vspec.adoc to clarify the idea.


Sharing my tentative understanding below (and some questions on ELEN and SEWLMUL1MAX), derived mainly from looking at the spike lmul checks and 3.3.2, curious as well if this captures the main intent of the fractional-lmul or there are aspects which are missing or equations require adjustment:


  • Goal clarification:

    • Fractional LMUL allows the result of widening operations to be definitively contained within a single vector register.

    • The advantage this provides seems (at least) two-fold

      • Any register is usable for widening with fractional LMULs (opposed to integer LMUL can be used only for registers evenly divisible by the LMUL, e.g. v0, v8, v16, v24 for LMUL = 8).

      • Related to above, less registers are locked down by the application of widening, reducing register availability bottlenecks and the needed number of stores/loads to-and-from memory.

    • In order to ensure that the result of widening operations can be contained in a single register, there are certain constraints (see below)
  • Constraints:

    • SEW <= ELEN*VFLMUL

      • Example 1: ELEN = e32, VFLMUL= ⅛

        • SEW <= ELEN*VLMUL = 4, VFLMUL ⅛ illegal for ELEN e32

      • Example 2: ELEN e32, VFLMUL = ¼

        • SEW <= ELEN*VFLMUL = 8, therefore SEW must be e8

      • Example 2: ELEN e32, VFLMUL = ½ 

        • SEW <= ELEN*VLMUL = 16, therefore SEW must either e8, e16

    • Note: For architectures where ELEN > SEWLMUL1MAX, one would go throught the same exercise as above but with s/ELEN/SEWLMUL1MAX.

  • Where to store/how-to-derive of ELEN and/or SEWLMUL1MAX:

    • ELEN/SEWLMUL1MAX are not stored in CSR’s, ELEN may be derived from the extension:

      • Example: ELEN = e32 for ZVE32x

    • SEWLMUL1MAX storage/derivation questions (this particular one is unclear to me):

      • If ELEN > SEWLMUL1MAX, how would one derive SEWLMUL1MAX from the ELEN?

      • Where (e.g. any CSR) would the SEWLMUL1MAX be stored?

      • Would this be derived from knowing the specific extension and perhaps the Vlenb and held in a special architecture specific register?


Suggested edits for discussion: 

  • Adding SEW equation, possibly in mathematical notation, to clarify the policy

  • Adding some examples to clarify the policy

  • Adding goal/intent and advantages of using fractional-lmul vs lmul and vice versa


Would be happy to contribute pull requests after confirming whether this understanding is correct, and clarifying questions about the SEWLMUL1MAX/ELEN derivation/storage.


All the best,

Gregory


Multiple accesses required to the same location for strided memory accesses

Bill Huffman
 

I see that section 7.5 of the vector spec currently says:

 

When rs2=x0, then an implementation is allowed, but not required, to perform fewer memory operations than the number of active elements, and may perform different numbers of memory operations across different dynamic executions of the same static instruction.

 

Note Compilers must be aware to not use the x0 form for rs2 when the immediate stride is 0 if the intent to is to require all memory accesses are performed.

 

When rs2!=x0 and the value of x[rs2]=0, the implementation must perform one memory access for each active element (but these accesses will not be ordered).

 

Note When repeating ordered vector accesses to the same memory address are required, then an ordered indexed operation can be used.

 

I’m not sure from reading this whether strided accesses that overlap are required to read the memory location multiple times.  The first three paragraphs sound like they are.  The fourth paragraph (the note) sounds like they are not – if one wants multiple accesses of the same memory location, one should use an ordered indexed operation (with constant index).

 

I thought we had said that the ordered indexed operations were the only ones that were constrained to access memory as many times as the naïvely interpreted instruction said.  That seems to mean the first three paragraphs should be changed.

 

It would seem quite unfortunate to require strided memory operations to be special cased for zero stride (but not x0).  If so, we also need to say what happens for positive and negative strides with absolute value less then the element size being accessed – or, for segmented accesses, less than the multiple segment size.

 

If strided, segmented loads where the stride is one segment are required to do multiple accesses, that would be even more unfortunate as it would keep them from being used efficiently for stencil operations.

 

      Bill


Re: Zve should be a strict subset of V, use new option to relax VLEN

ghost
 

* I wonder if there could be a table for what Zve* and V include in instructions with both YES and NO on appropriate lines of the table for what each extension must include. The statements, understandably, include what instructions are supported. But I have trouble with the process-of-elimination to see what's not included as well as with the comparison of Zve to V.
FYI, I'm working with Elisa Sawyer and others on a style and content guide for extension proposals, mostly based on the excellent bitmanip v1.0.0-rc1 draft. That draft includes a table like the one you're suggesting, and I'm advocating putting that in the guide as a recommendation.

--

L Peter Deutsch <ghost@major2nd.com> :: Aladdin Enterprises :: Healdsburg, CA

Was your vote really counted? http://www.verifiedvoting.org

101 - 120 of 790