Re: Smstateen for Zcmt

Allen Baum

 Greg, you said:
 "The intent is that if Smstateen is needed to provide a backward compatibility mechanism, 
   then the extension AS A WHOLE would be enabled or disabled.
  (This, as I noted earlier, should be a rare case.)"

The spec for Msstateen says:
In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA extensions that introduce the controlled state.

It sounds like this is that rare case: Smstateem enable bit is required because they are incompatible, 
So it must control both the access to the CSRs and all instructions defined by that extension  - even if some particular op doesn't change processor state (beyond Rd)
Then, why is a custom enable/disable required ?
(and possibly a bit more complicated: if misa.D, Smstateen.Zcmt can't both be set, so setting one must clear the other)

OR is that extra bit of functionality what makes it custom - though that would be the requirement of any extension that conflicts with other extension,
which should probably be made part of the spec so we don't go through this exercise every  time it happens.
Though I supposed I'd be happy if it never happens again...

On Mon, May 16, 2022 at 12:32 PM Greg Favor <gfavor@...> wrote:
On Mon, May 16, 2022 at 12:19 PM Allen Baum <allen.baum@...> wrote:
Doesn't Zcmt repurpose FP opcodfes, so is in that second rare case?

Zcm* all reuse encodings for c.fld, c.fsd, c.fldsp, c.fsdsp

Then my earlier parenthetical comment is relevant:  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)
Off-hand (maybe naively) I would imagine that implementations will either implement the D extension or the Zcmt extension - as a fixed choice.  RVA-compliant implementations must implement D, so this is a non-issue for such designs.  It is only non-RVA embedded designs that either care about code size reduction enough to want Zcmt and don't care about having DP FP, or vice-versa.  If there was ever such a design that wanted to support both, even though only one of the two extensions could be used by software in a given system using that design, then a custom enable/disable bit could be used by that design.


Join to automatically receive all group messages.