3 ms·

I wasn't aware that we already have so many extensions. But doesn't the binary get more bloated the more extensions you have?

• dzaima 5y ago
  In practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a specific target architecture just won't ever use AVX/AVX2/AVX-512/any other extension. There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.
  • snvzz 5y ago
    >but I don't know what, if any, are RISC-V's plans for that. Profiles. See RVA22.
• demindiro 5y ago
  You can choose which extensions to support at compile time and whether this extension is optional. E.g. many binaries don't use AVX at all, while binaries compiled with -march=native may assume that AVX is supported (and emit SIGILL if not).
• rwmj 5y ago
  With x86 there are common extensions that form a baseline (eg. you need SSE2 for any program to run at all). And there are more specialized extensions, eg. for high performance mathematical work. The specialized extensions can usually be confined to a library, and the library can work out at runtime what the hardware supports and swap in optimized functions. It'll likely work much the same way for RISC-V, eg. in Fedora we require that the C (compressed) extension is supported, otherwise the distro won't boot, and things like the vector extension will probably be used only by specialized math libraries and the like.