> 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 fund

> 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.