martinmaas
commented
3 months ago The decision to split the decision was made by the overarching RISC-V architecture review committee. The reason for these different extensions is to bring them into a format that they can be included in the standardized profiles, which are intended to avoid the fragmentation problem that you mention:
https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc
While the specification defines 5 extensions, the way they are used in the profile ensures that the only optionality is whether or not to support S-mode pointer masking (Smnpm). M-mode pointer masking (Smmpm) is outside the scope of the profile since M-mode is under control of vendors and thus should be entirely separate. Supm and Sspm are "pseudo-extensions" needed to refer to functionality that crosses the privilege mode boundary within profiles; they have no functionality attached nor could anyone implement them directly.
This may be late to (re)consider, but it seems pretty artificial to consider this as five independent extensions.
We've already seen that silicon vendors will take advantage of any possible flexibility. It's easy to argue that's a feature, not a bug, but it means that operating systems, in particular, will have to deal with the possibility of there being not one extension, but 2^5 extensions to deal with every possible (and often nonsensical) combination of having and not having each of these. It seems the implementation cost of each of these is likely to be low for any chip large enough to support any of these. Having Smnpm without Sspm, as an example, but the fact that it's possible seems to make it a near certainty that someone, somewhere will build such a thing.
RISC-V is already suffering from the F word as implementations choose from the smorgasboard of scores of extensions. Please don't contribute further to this. Consider making this one extension that says, for example, that bits 33:32 of m*cfg are reserved/undefined even if this extension isn't present or that they must be written as 0's even if these extensions aren't present/wanted. It has no practical cost (hopefully existing implementations aren't setting reserved bits) and it would allow treating this whole collection as one "pointer masking" extension instead of defining an extension for the presence or absence of them.
Note that my examples may be tripped up in the phrasing. Please don't fixate on them, but instead register my plea that we reduce the cognitive load of systems software/tool developers and prefer snowflakes of extensions over avalanches of individual, super light-weight "extensions' that may or may not be present. (This plea generally applies to all extensions...)
Thank you for listening.