Re: proposal for stateen CSRs
Greg Favor
On Wed, Jun 16, 2021 at 10:06 AM Josh Scheid <jscheid@...> wrote:
Instead of linear CSR expansion 4-8-? CSRs, should the mechanism provide for a future transition to an indirect state space? That would need perhaps just two registers for address and data. I acknowledge the value of the direct state, but I think it would be better to explicitly reject using such a scheme at this point (or reserving encoding space for moving to it).
Past discussions considered 4 CSRs to last for a long time, i.e. we can place bets on whether that lasts >30 years, >20 years or >10 years. An option, not cast in concrete, for 8 CSRs provides one possible growth path if needed.
It would be good to explicitly state whether or not these registers can be used for discovery or must not. If not for discovery, then bits are Reserved and must not be set by SW that doesn't already know that an extension exists or perhaps doesn't know that the implementation implements that extension. If for discovery, then individual extensions and implementations need to behave in a "safe" manner when bits are toggled blindly.I think avoiding utility as discovery would be cleaner, as it reduces the number of redundant discovery mechanisms. This is assuming that other methods for discovery exist.
Agreed. These should not be allowed for use as a discovery method. People should be referred to the new (and coming) standard RISC-V discovery method that all extensions will be required to use.
One could argue that since support for the new method will be added to the DoD requirements checklist for all extensions, that at most a non-normative comment here would be justified.
It's natural to me that extensions that don't have state (instructions only) would want a similar mechanism to control extension enablement. Paul Donahue brought this up earlier, but I saw no reaction. Is this proposal limited to stateful extensions with the thought of some other mechanism for stateless ones? Why would the architecture want a different mechanism, or should this mechanism be expanded to accommodate stateless extensions (mextenN?).
I'm not expressing an argument for or against, just noting that Unpriv-related
(and some Priv-related)
extensions - currently ratified or heading to ratification this year - generally don't/won't have an overall enable/disable control. One can certainly argue that this practice, or guidelines more properly, should be officially documented. And maybe a discussion needs to happen first to get consensus on what the guidelines should be.
The field consumption will happen a bit faster due to provisional allocation. Many nascent or stalled extension proposals may be allocated a field provisionally, then enter purgatory or be retracted, meanwhile other extensions will overtake and allocate further fields, causing "holes", which may be impossible to deallocate if provisional extensions are out in the field. I could imagine having a separate allocation scheme for provisionals, which then get a different permanent allocation as part of ratification. Or we move to an indirect scheme where the state space is "free". Or perhaps this isn't a real problem?
Maybe not a real problem since bit assignment could be done as part of Arch Review of the final extension spec (i.e. very late in the game and, based on the Arch Review results, it will be clear if the extension is going to be heading on down the path towards ratification or not).
Greg