|
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
|
|
|
toggle quoted message
Show quoted text
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!
|
|
|
Jim Wilson
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 (吴伟)
toggle quoted message
Show quoted text
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 (吴伟)
|
|
|
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.
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.
toggle quoted message
Show quoted text
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 (吴伟)
|
|
|
Hello Jim, Where could I find the last clang build for v1p0?
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
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
Hello Jim, Where could I find the last clang build for v1p0?
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
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 (吴伟)
|
|
|
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.
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
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
Hello Jim, Where could I find the last clang build for v1p0?
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
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
Where could I find the last clang build for v1p0?
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@...> wrote:
On Sat, Sep 18, 2021 at 3:57 PM Mick Thomas Lim <mickthomaslim@...> 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 (吴伟)
|
|
|
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
toggle quoted message
Show quoted text
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.
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.
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.
Hello Jim,
Where could I find the last clang build for v1p0?
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!
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 (吴伟)
|
|
|
