Re: Configuring qemu for Vector Extension

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:


Linker used, this was a special build for me by Embercosm with a full library build (– thank you Embercosm):


QEMU used was Git cloned from (at the time) the latest RISC-V Vector QEMU branch from SiFive:

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,






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):


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.





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.





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:

But this e-mail appears to indicate that only v0p10 is supported so far:


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!




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:
>> gcc:
>> binutils:
>> 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.
>> >
>> > Jim
>> >
>> >
>> --
>> Best wishes,
>> Wei Wu (吴伟)

Best wishes,
Wei Wu (吴伟)

Join to automatically receive all group messages.