toggle quoted messageShow quoted text
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:
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.
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:
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.
Wei Wu (吴伟)
Wei Wu (吴伟)