1. Tech-Privileged
  2. Topics

Smstateen for Zcmt

John Hauser
 

Mark wrote:
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?
We expect people to implement the new Zcm* extensions together with Zca
and Zcb. Zca is the subset of C that drops the compressed instructions
for double-precision floating-point loads and stores. The expectation
is that most embedded systems will find the new compressed instructions
more useful than the existing ones for double-precision floating-point,
especially as smaller embedded systems typically don't do double-
precision floating-point at all. But even for those that do, they can
still have the standard non-compressed D instructions together with Zca
+ Zcb + all of Zcm*.

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.
The total number of 16-bit encodings is too small to contain everything
we might want to put in that space. Choices must be made.

- John Hauser
John Hauser
 

Tariq Kurd wrote:
Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.
Can I allocate bit 2 as follows?
Yes, let's assume bit 2 is allocated for this purpose, in mstateen0,
hstateen0, and sstateen0.

*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?
We'll probably change the wording later, but for now, replace the
word _encodings_ by _instructions_, and drop "For convenience".
Instructions CM.JT and CM.JALT must trap because they implicitly depend
on the value of jvt.

..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.
Right. The intention is that stateen bits should be for controlling
access to new state. No state, no stateen bit.

- John Hauser
Tariq Kurd
 

ok, thanks John, I've done the rewording.

Tariq

On Mon, 23 May 2022 at 02:46, John Hauser <jh.riscv@...> wrote:
Tariq Kurd wrote:
> Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.

> Can I allocate bit 2 as follows?

Yes, let's assume bit 2 is allocated for this purpose, in mstateen0,
hstateen0, and sstateen0.

> *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?

We'll probably change the wording later, but for now, replace the
word _encodings_ by _instructions_, and drop "For convenience".
Instructions CM.JT and CM.JALT must trap because they implicitly depend
on the value of jvt.

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

Right.  The intention is that stateen bits should be for controlling
access to new state.  No state, no stateen bit.

    - John Hauser


--

Tariq Kurd | Chief CPU Architect | Codasip UK Design Centre | www.codasip.com

21 - 23 of 23