4 ms·

Thanks for the update - IMO the debacle ranges over the last 4 years or so, where GCC refused to upstream support for RVV 0.7 until now (14.1) and that only li

by mappu 2y ago

Thanks for the update - IMO the debacle ranges over the last 4 years or so, where GCC refused to upstream support for RVV 0.7 until now (14.1) and that only living in out-of-tree vendor toolchains, and so all the most popular boards (all with C906/C910) were unable to run RVV binaries compiled with standard distro-packaged GCC. Thus making the vector unit largely useless without a custom toolchain or (more likely) whole BSP/rootfs. My ideal would be if the ordinary Debian binary port could make something useful out of either RVV version if present, without needing a special board rootfs or custom glibc build. > much useful code is binary compatible between them (e.g. all the C library string functions, memcpy etc) I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0, that sounds extremely promising for glibc. I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? The x86_64 version of this logic is in sysdeps/x86_64/stpcpy.S , it automatically switches to a sse2/avx2/evex implementation if those ISA extensions are present. It looks like the Linux kernel's memcpy does not attempt to use V at all neither (as of 6.9 arch/riscv/lib/memcpy.S),

rwmj 2y ago
> I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? Last I heard the glibc developers are waiting for a decent hardware platform to target. You need something that supports V1.0, is widely available, and performs something like we expect future hardware to perform so you don't end up optimizing for the wrong things. (Qemu is no use because the performance of emulated V is very different from the real thing since every V instruction goes through a TCG helper function.)
brucehoult 2y ago
> GCC refused to upstream support for RVV 0.7 until now IMHO the GCC people were being dumb. They don't want to upstream support for "draft" specs. That's fundamentally because it will be obsolete as soon as there's a new draft. But that should go out the window as soon as someone makes commercial hardware using that spec -- at that point it's frozen and those real-world users have a right to expect hardware they paid for to be supported. There was also the qustion of who will do the work, and THead and Allwinner and other interested parties in China were not quick to step up to do it. > I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0 Sure. For example here is something I posted in April 2021, tested on a prototype AWOL Nezha D1 board I got ssh access to in China a few months before customers started to receive them in late June / early July. https://hoult.org/d1_memcpy.txt https://hoult.org/d1_memcpy.txt Of course RVV 1.0 was not final then. But it turns out that if you change the `vlb.v` instruction to `vlbu.v` (which doesn't change the functionality as it's loading bytes in RAM to bytes in a vector register) then that maps to `vle8.v` in RVV 1.0. All the other instructions used are binary compatible with the equivalent RVV 1.0 instruction.

by mappu 2y ago

rwmj 2y ago

> I had a quick glance at the glibc source code and didn't find anything other than a C implementation - do you know if that's a recent innovation or what version of glibc supports that? Or is any V implementation in glibc's string functions just relying on the compiler autovectorization (does that exist for RVV)? Or is this not upstream yet? Last I heard the glibc developers are waiting for a decent hardware platform to target. You need something that supports V1.0, is widely available, and performs something like we expect future hardware to perform so you don't end up optimizing for the wrong things. (Qemu is no use because the performance of emulated V is very different from the real thing since every V instruction goes through a TCG helper function.)

brucehoult 2y ago

> GCC refused to upstream support for RVV 0.7 until now IMHO the GCC people were being dumb. They don't want to upstream support for "draft" specs. That's fundamentally because it will be obsolete as soon as there's a new draft. But that should go out the window as soon as someone makes commercial hardware using that spec -- at that point it's frozen and those real-world users have a right to expect hardware they paid for to be supported. There was also the qustion of who will do the work, and THead and Allwinner and other interested parties in China were not quick to step up to do it. > I didn't realize common libc functions could be made binary compatible between RVV 0.7 and 1.0 Sure. For example here is something I posted in April 2021, tested on a prototype AWOL Nezha D1 board I got ssh access to in China a few months before customers started to receive them in late June / early July. https://hoult.org/d1_memcpy.txt https://hoult.org/d1_memcpy.txt Of course RVV 1.0 was not final then. But it turns out that if you change the `vlb.v` instruction to `vlbu.v` (which doesn't change the functionality as it's loading bytes in RAM to bytes in a vector register) then that maps to `vle8.v` in RVV 1.0. All the other instructions used are binary compatible with the equivalent RVV 1.0 instruction.