OK, thanks everyone, interesting debate.
BTW it's not only Zcmt which has conflicting opcodes with C (encoding C.FSD, C.FSDSP, C.FLD, C.FLDSP), it's also the case for all Zcm* (Zcmb Zcmp Zcmpe Zcmt).
So if we want to disable opcode conflicts, then we'll need to do so for all of those.
Note for Jeff: this is our method of dramatically improving the code-size - we need to reuse some of the 16-bit encoding space to be competitive with other embedded architectures.
Personally I agree with the concept of building a C compatible core or Zcm* compatible core as a design choice, and if someone _really_ wants a switch then they can implement a custom bit to control it, but this seems like an unlikely use case.
Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.
Referring to this existing text for Zfinx stateen:
>Bit 1 applies only for the case when floating-point instructions operate on x registers instead of f registers.
>Whenever misa.F = 1, bit 1 of mstateen0 is read-only zero (and hence read-only zero in hstateen0 and sstateen0
>too). For convenience, when the stateen CSRs are implemented and misa.F = 0, then if bit 1 of a controlling
>stateen0 CSR is zero, all floating-point instructions cause an illegal instruction trap (or virtual instruction trap, if
>relevant), as though they all access fcsr, regardless of whether they really do.
Can I allocate bit 2 as follows?
Bit 2 applies only for the case that Zcmt is implemented, which includes the JVT CSR and the cm.jt, cm.jalt encodings.
For convenience if bit 2 of a controlling stateen0 CSR is zero, then all cm.jt, cm.jalt instructions cause an illegal instruction trap
(or virtual instruction trap, if relevant).
..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.
