Allen Baum
Emulating systems that don’t support some extension either has SW that doesn’t use the extension, in which case it does t matter if the extension is enabled or disable, or does use it, in which case the more capable system will execute it natively.
If the less capable system is non-conforming - using those opcodes for something else, then you have to -guarantee that disabled extensions trap - guarantee that all the custom ops used by the less-capable implementation are a subset of the disabled extension.
This getting pretty far out into left field, IMHO.
On Sep 11, 2020, at 4:17 PM, Andrew Waterman < andrew@...> wrote:
OK - taking a step back, what about requiring: any extension spec that doesn't specifically discuss enabling and disabling should be prohibited from enabling or disabling.. I can't see any good use cases - even for power, given the F/D method of dealing with that via the XS bits.
Emulating less-capable systems. That is a very explicit mechanism, specifically architected for enabling and disabling, with all the side effects and corner cases defined (one hopes).
On Thu, Sep 10, 2020 at 4:13 PM Paul Donahue < pdonahue@...> wrote: The hypervisor spec specifically says that implementations should have writable misa so this isn't theoretical: "The hypervisor extension is enabled by setting bit 7 in the misa CSR, which corresponds to the letter H. When misa[7] is clear, the hart behaves as though this extension were not implemented, and attempts to use hypervisor CSRs or instructions raise an illegal instruction exception. Implementations that include the hypervisor extension are encouraged not to hardwire misa[7], so that the extension may be disabled. "
And, of course, the misa register says that extensions may be disabled, that both E and I may be implemented and that misa is the way to select between them, etc. I don't know if anybody has actually done those things, though.
I thought there was already a speced requirement that, at reset, all extensions are enabled.: "At reset, the
Extensions field shall contain the maximal set of supported extensions, and I shall be selected over
E if both are available."
And then there are the corner cases: if there are no misa bits for subsets (e.g Zbb, Zv<whatever>), then they can't be enabled or disabled. So, why should misa. bits for the full extensions allow enabling/disabling? What does it mean for misa.G to be enabled or disabled? misa.I ?(if misa.E isn't also present)?
Has anyone identified use cases for turning extensions on and off? (as opposed to FP-like disabled state to save power). Has anyone ever implemented RW misa bits? IF not: why not just require those MISA bits to be RdOnly?
On Thu, Sep 10, 2020 at 10:44 AM Greg Favor < gfavor@...> wrote: A potential second general requirement for all Priv extensions:
- The hart reset state must be fully specified and should generally be UNSPECIFIED except for any key control/status bits that need to be in a specific state. (This minimizes hardware cost and leaves probably the large majority of state to be initialized by software.)
- The reset state should also specify one of: a) The extension is "disabled" (and most, if not all, other extension state is don't care).
b) The extension is "enabled" and any key control/status bits are initialized to specific values as necessary (with all the rest UNSPECIFIED and left to be initialized by software).
Greg
|
