4 ms·

I didn't realize RISC-V already has so many extensions. I just briefly looked over them and apparently they are often just small parts which get grouped up into

I didn't realize RISC-V already has so many extensions. I just briefly looked over them and apparently they are often just small parts which get grouped up into larger extensions, but I hope the extension "mess" won't kill risc-v in the end. Still very excited about RISC-V progress

rwmj 2y ago
You may like ... https://research.redhat.com/blog/article/risc-v-extensions-whats-available-and-how-to-find-it/ https://research.redhat.com/blog/article/risc-v-extensions-w... I don't think extensions are a "mess", certainly they're much less of a mess than x86 (a low bar, I know ...)
- snvzz 2y ago
  Good article, although not up to date with happenings within RVI. Most remarkable is the mention of issues around C. This got extensive discussion. It turned out only Qualcomm has issues, and the rest of companies with large scale implementations are happy with C. It was proven in these discussions that the issues Qualcomm brought up are specific to their implementation largely reusing the ARM core they obtained from Nuvia acquisition, and easy to avoid with a clean board implementation. The board ultimately ruled against Qualcomm's proposal[0], and the world moved on. Note that every purchasable chip out there supports C, and this is unlikely to change. 0. https://news.ycombinator.com/item?id=38230463 https://news.ycombinator.com/item?id=38230463
dkjaudyeqooe 2y ago
For RISC-V, it's extensions all the way down. The mandatory core is tiny and all the value (outside of minuscule microcontrollers) is in the extensions. It makes more sense if you think about it like programming libraries. That's the same 'mess', but it's not a problem. There is often fear of 'fragmentation', but vendors tend to be highly responsive to their target market and competitors for each application and will coalesce around a set of extensions that make sense. The other thing I'd add is that the one thing worse than having 'yet another extension' is not having the extension you need. Extensions are a response to market demand.
- mikepurvis 2y ago
  Speaking as someone with zero actual domain knowledge, my concern would be about ensuring that disparate extensions have consistent interfaces and can cooperate with each other. I don't know how that would work at a hardware design level, but the thing to avoid would be whatever is the analogue of the rust/async fiasco, where certain components only really work properly with others within their own "sub" ecosystem.
snvzz 2y ago
Software does mostly target Profiles, such as RVA22 (latest ratified application profile). They specify a set of extensions that is required. Note that all software compiled for RVA20 does still run on RVA22 CPUs. but software built for RVA22 does not (directly, trapping and emulating is possible) run on the older RVA20 CPUs, as they lack the necessary instructions. This is not unlike e.g.: x86-64v3 vs x86-64v2. It is only in situations where the implementation is very small and vendor has full control of both the software and the hardware stack that the vendor might benefit from implementing exactly what they want. CPUs and software stacks for servers, workstations, laptops, smartphones, tablets and such simply stick to profiles. Windows and Android are expected to require RVA22+V, possibly RVA23, as the baseline.

rwmj 2y ago

You may like ... https://research.redhat.com/blog/article/risc-v-extensions-whats-available-and-how-to-find-it/ https://research.redhat.com/blog/article/risc-v-extensions-w... I don't think extensions are a "mess", certainly they're much less of a mess than x86 (a low bar, I know ...)

snvzz 2y ago
Good article, although not up to date with happenings within RVI. Most remarkable is the mention of issues around C. This got extensive discussion. It turned out only Qualcomm has issues, and the rest of companies with large scale implementations are happy with C. It was proven in these discussions that the issues Qualcomm brought up are specific to their implementation largely reusing the ARM core they obtained from Nuvia acquisition, and easy to avoid with a clean board implementation. The board ultimately ruled against Qualcomm's proposal[0], and the world moved on. Note that every purchasable chip out there supports C, and this is unlikely to change. 0. https://news.ycombinator.com/item?id=38230463 https://news.ycombinator.com/item?id=38230463

dkjaudyeqooe 2y ago

For RISC-V, it's extensions all the way down. The mandatory core is tiny and all the value (outside of minuscule microcontrollers) is in the extensions. It makes more sense if you think about it like programming libraries. That's the same 'mess', but it's not a problem. There is often fear of 'fragmentation', but vendors tend to be highly responsive to their target market and competitors for each application and will coalesce around a set of extensions that make sense. The other thing I'd add is that the one thing worse than having 'yet another extension' is not having the extension you need. Extensions are a response to market demand.

mikepurvis 2y ago
Speaking as someone with zero actual domain knowledge, my concern would be about ensuring that disparate extensions have consistent interfaces and can cooperate with each other. I don't know how that would work at a hardware design level, but the thing to avoid would be whatever is the analogue of the rust/async fiasco, where certain components only really work properly with others within their own "sub" ecosystem.

snvzz 2y ago

Software does mostly target Profiles, such as RVA22 (latest ratified application profile). They specify a set of extensions that is required. Note that all software compiled for RVA20 does still run on RVA22 CPUs. but software built for RVA22 does not (directly, trapping and emulating is possible) run on the older RVA20 CPUs, as they lack the necessary instructions. This is not unlike e.g.: x86-64v3 vs x86-64v2. It is only in situations where the implementation is very small and vendor has full control of both the software and the hardware stack that the vendor might benefit from implementing exactly what they want. CPUs and software stacks for servers, workstations, laptops, smartphones, tablets and such simply stick to profiles. Windows and Android are expected to require RVA22+V, possibly RVA23, as the baseline.