4 ms·

RISC-V looked at that and said "Watch me, I can do even more". Also, it's a safe assumption that everyone is on x86-x64-v2 now which includes up to SSE4.2. And

RISC-V looked at that and said "Watch me, I can do even more". Also, it's a safe assumption that everyone is on x86-x64-v2 now which includes up to SSE4.2. And almost everyone is on x86-x64-v3 which includes AVX2. In practice there are about three main "bubbles" of supported extensions. Intel did try to throw a wrench into that with AVX512 but luckily AMD took a saner route and everything converges on more or less the same set of supported subsets of AVX512.

cmrdporcupine 2y ago
Nah, RISC-V looked at that and decided to formalize the concept of extensions properly and put it through a proper standards process instead of letting it be dominated by the whims of manufacturer's product and marketing pipeline.
- pclmulqdq 2y ago
  And then formalize enough of them that there are now over 1 quintillion valid ways to create a standards-conforming RISC-V core.
  - snvzz 2y ago
    Not a concern, as the common ecosystem of binary software follows RVA profiles. Microcontrollers / embedded can go wild, as the vendor controls the whole stack and can build its firmware images to suit the system.
    - pclmulqdq 2y ago
      The big promise of RISC-V for embedded was that vendors would not have to maintain toolchains like that. There's no real benefit over using a proprietary core if you have to maintain your toolchain. That's a big reason why they use Arm cores.
      - snvzz 2y ago
        Absolutely, that's why the toolchains (gcc and llvm) support specifying which extensions to use. Most people are gonna build for a profile, but embedded can build for whatever custom set of extensions the core they are using has, which does not have to be a profile.
        cmrdporcupine 2y ago
        +1. It's a weird thing to complain about considering building for ARM already involves a bunch of board specific compiler arguments in regards to FPU, MMU, etc. If anything, choosing the extension set is cleaner.

cmrdporcupine 2y ago

Nah, RISC-V looked at that and decided to formalize the concept of extensions properly and put it through a proper standards process instead of letting it be dominated by the whims of manufacturer's product and marketing pipeline.

pclmulqdq 2y ago
And then formalize enough of them that there are now over 1 quintillion valid ways to create a standards-conforming RISC-V core.
- snvzz 2y ago
  Not a concern, as the common ecosystem of binary software follows RVA profiles. Microcontrollers / embedded can go wild, as the vendor controls the whole stack and can build its firmware images to suit the system.
  - pclmulqdq 2y ago
    The big promise of RISC-V for embedded was that vendors would not have to maintain toolchains like that. There's no real benefit over using a proprietary core if you have to maintain your toolchain. That's a big reason why they use Arm cores.
    - snvzz 2y ago
      Absolutely, that's why the toolchains (gcc and llvm) support specifying which extensions to use. Most people are gonna build for a profile, but embedded can build for whatever custom set of extensions the core they are using has, which does not have to be a profile.
      - cmrdporcupine 2y ago
        +1. It's a weird thing to complain about considering building for ARM already involves a bunch of board specific compiler arguments in regards to FPU, MMU, etc. If anything, choosing the extension set is cleaner.