5 ms·

OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward p

OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask.

snvzz 3y ago
>OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. GNU toolchain supports 0.7.1. What we don't know is if it will do so forever, or remove it. >For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask. However, If a company has a need for this sort of compute and has and full control of their stack, these chips can be useful and are already available. For an enthusiast it's alright as long as not much money is spent (e.g. Sipeed LM4A), at worst (if there ceases to be an ecosystem for 0.7.1 V) what you've got then is a chip with no V. One that's significantly faster than the one used in VisionFive 2, which does actually not have V in any form or shape. For end users that don't care about RISC-V and want an SBC, next year (or perhaps late this year) there'll be RVA22+V options, and a much more mature ecosystem; I own VF2 (the first RISC-V SBC to actually ship large numbers), and I have seen how fast the ecosystem has accelerated since its release.
- CameronNemo 3y ago
  Do you have a source on GCC supporting v 0.7.1? That is contrary to what I've read.
  - snvzz 3y ago
    On a personal level, I prefer upstream not to have anything non-ratified. Companies that use these should bear the cost of maintaining the toolchain, not upstream. There's this tree[0] which has support. I thought it actually got merged, but I'm currently struggling to find anything about it. 0. https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0.7.1 https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0...
    - brucehoult 3y ago
      My repo is relatively old, gcc 9.2.0. Not that there's anything much wrong with gcc from August 2019! I've been using gcc since 2002. THead have a newer version based on gcc 10.2.0. https://github.com/T-head-Semi/xuantie-gnu-toolchain https://github.com/T-head-Semi/xuantie-gnu-toolchain But it doesn't really matter. There is no support in the C language for RVV 0.7.1, you just have to write either plain assembly language or inline asm for your RVV code. Which means you need a binutils that supports RVV 0.7.1 to assemble your vector code, but you can compile the rest of your program with the latest upstream gcc. Then you can link the .o files. Note that even though there is support for RVV 1.0 "intrinsic functions" in C compilers, SiFive just submitted RVV 1.0 support for FFmpeg and it's written in pure assembly language. https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.html https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.ht...

snvzz 3y ago

>OK, but that doesn't change the fact that if you actually want to use the vector extension on this CPU you'll be using a very out of date compiler, or forward porting the 0.7.1 support to a newer toolchain. GNU toolchain supports 0.7.1. What we don't know is if it will do so forever, or remove it. >For someone buying a quad core SBC that may not be a big deal, but 64 cores that you can't cleanly use to their full potential is a bit of an ask. However, If a company has a need for this sort of compute and has and full control of their stack, these chips can be useful and are already available. For an enthusiast it's alright as long as not much money is spent (e.g. Sipeed LM4A), at worst (if there ceases to be an ecosystem for 0.7.1 V) what you've got then is a chip with no V. One that's significantly faster than the one used in VisionFive 2, which does actually not have V in any form or shape. For end users that don't care about RISC-V and want an SBC, next year (or perhaps late this year) there'll be RVA22+V options, and a much more mature ecosystem; I own VF2 (the first RISC-V SBC to actually ship large numbers), and I have seen how fast the ecosystem has accelerated since its release.

CameronNemo 3y ago
Do you have a source on GCC supporting v 0.7.1? That is contrary to what I've read.
- snvzz 3y ago
  On a personal level, I prefer upstream not to have anything non-ratified. Companies that use these should bear the cost of maintaining the toolchain, not upstream. There's this tree[0] which has support. I thought it actually got merged, but I'm currently struggling to find anything about it. 0. https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0.7.1 https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0...
  - brucehoult 3y ago
    My repo is relatively old, gcc 9.2.0. Not that there's anything much wrong with gcc from August 2019! I've been using gcc since 2002. THead have a newer version based on gcc 10.2.0. https://github.com/T-head-Semi/xuantie-gnu-toolchain https://github.com/T-head-Semi/xuantie-gnu-toolchain But it doesn't really matter. There is no support in the C language for RVV 0.7.1, you just have to write either plain assembly language or inline asm for your RVV code. Which means you need a binutils that supports RVV 0.7.1 to assemble your vector code, but you can compile the rest of your program with the latest upstream gcc. Then you can link the .o files. Note that even though there is support for RVV 1.0 "intrinsic functions" in C compilers, SiFive just submitted RVV 1.0 support for FFmpeg and it's written in pure assembly language. https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.html https://ffmpeg.org/pipermail/ffmpeg-devel/2023-May/309722.ht...