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


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


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


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


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






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


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


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


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


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
 


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


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