Re: Why must misa.H be writable (RVA22)?
Jonathan Behrens <behrensj@...>
I think the fact that the current platform spec draft lacks any way for S-mode to toggle misa.H, for S-mode to request a specific value, or even a way for configuring M-mode to set/unset misa.H at boot, is a strong indication that this isn't a broadly demanded feature. It seems reasonable to allow misa.H to be writable for the subset of cases that require it, but I see no reason to require it as part of the profile.
Jonathan
On Wed, Sep 8, 2021 at 12:57 PM Greg Favor <gfavor@...> wrote:On Wed, Sep 8, 2021 at 12:45 PM Andrew Waterman <andrew@...> wrote:My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.I don't disagree. Which begs the question of whether there should be any encouragement or expectation that any implementations (barring inevitable exception cases) of misa should have writable bits. Having all bits hardwired to 0 or 1 saves a bunch of design and DV work. The obvious next example to question is whether the V bit should be writable or not.I'm not arguing for disallowing having writable bits. But as a form of architectural guidance, when might it be considered justifiable to have writable H and/or V bits (or other misa bits)? Is it just the rare implementation exception cases?Without a doubt, there’s value in building machines that can faithfully emulate less-capable machines. With that in mind, writable misa.H is a well architected feature. Whether it rises to the level of a mandate in this platform is another matter, though.Greg