Note: lists.riscv.org will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
- Configuring qemu for Vector Extension
Re: Configuring qemu for Vector Extension
toggle quoted messageShow quoted text
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.
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 (吴伟)
Join firstname.lastname@example.org to automatically receive all group messages.