Re: Smstateen for Zcmt


Please explain to me why we would not want implementers to implement Zc* and not C. I am not sure I understand the use cases and workloads well. Am I misunderstanding?

I understand that implementers want to pick and choose in embedded environments but I'd think we'd want the ability to have them all available together.


On Tue, May 17, 2022 at 12:42 AM Tariq Kurd <tariq.kurd@...> wrote:
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). 

How does that sound?

..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.


On Tue, 17 May 2022 at 03:09, John Hauser <jh.riscv@...> wrote:
I wrote:
> Zca + Zcb is a subset of C.

Correction:  Zca is a subset of C; Zcb is not.

    - John Hauser


Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre |

Join to automatically receive all group messages.