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

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.

Tariq

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 | www.codasip.com

I wrote:
> Zca + Zcb is a subset of C.

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

    - John Hauser

On Mon, May 16, 2022 at 3:11 PM Allen Baum <allen.baum@...> wrote:

Then, why is a custom enable/disable required ?

Not required.  Just an option for the seemingly (?) rare design that implements both extensions and hence needs a bit to control which is enabled (and the other is disabled) - ASSUMING that there is not sufficient practical justification to provide a standard CSR bit for this purpose.

 

(and possibly a bit more complicated: if misa.D, Smstateen.Zcmt can't both be set, so setting one must clear the other)

Yep.

 

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.

I think I want to say yes?  But in any case the point is whether there is enough practical justification for having a standard bit that switches between these two extensions (which is not even a simple extension enable/disable bit, but an ISA switch bit).

To me it seems like the first question is whether introducing a standard ISA switch bit for Zcmt is addressing a real-world need versus just a theoretical need?  And if just the latter, then the rare exception of a design that implements both extensions can instead have a custom "ISA switch" bit.

Greg

On Mon, May 16, 2022 at 10:02 AM Tariq Kurd <tariq.kurd@...> wrote:

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.

The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.

My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.

The question which arose was prompted by this text from the Smstateen spec:

"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."

And so the question is whether the instructions are also disabled.

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.)

In the common use case for Smstateen and the case of Zcmt, this does not apply and only access to the new JVT CSR would be enabled or disabled,

Greg

HI Greg,

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.

The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.

My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.

the question which arose was prompted by this text from the Smstateen spec:

On Mon, 16 May 2022 at 17:36, Greg Favor <gfavor@...> wrote:

Tariq,

Thanks for enquiring about new ISA extension coordination with the Smstateen extension that was ratified last year.

The first thing to note is that the primary purpose of and motivation for Smstateen is to close off covert communication channels created by new extensions that add new arch state that needs to be context switched (but may not be context switched by an unaware OS or hypervisor).  (A secondary usage of Smstateen is for rare cases of extensions that are not backward compatible and need to be disablable for backward compatibility.)  This extension is not intended to provide a general mechanism for disabling arch extensions.  Many extensions don't need such and one that does would define its own appropriate mechanism based on the nature of the extension.  (Smepmp, for example, implicitly provides practical backward compatibility by how it defines the semantics of the new CSR bits that it introduces - such that new or modified functionality only becomes active when explicitly enabled by software.)

The second thing to note is that Smstateen, as ratified last year, comprehended the few other extensions that were ratified last year that needed Smstateen support.  Going forward, a new ISA extension that fits the preceding primary and secondary Smstateen use cases should specify any new bit(s) it adds to the *stateenX CSRs.  Then, once it is ratified, this should be moved into the Smstateen chapter that will exist in the Priv spec (when the Smstateen extension itself is merged into the Priv spec - tbd whether before or after Priv conversion to adoc).  The post-ratified ISA extension spec should retain a short mention of and cross reference to the added Smstateen bit(s).

This will put all the new arch functionality introduced by a new ISA extension into one spec document for use during TG reviews, Arch Review, Tech Chairs/TSC/BoD votes, and public review.  Then the added Smstateen detailed functionality can be moved into the Smstateen chapter after ratification.

Regarding Zcmt in particular (which is due to be ratified this year I believe), it seems like adding Smstateen functionality might be necessary only if Zcmt breaks backward compatibility by redefining existing defined opcodes.  I don't remember if that applies here.  (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.)

Greg

On Mon, May 16, 2022 at 6:58 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:

In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.

As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:

Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks

Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:

Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).

There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.

https://github.com/riscv/riscv-code-size-reduction/issues/160

Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

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

--

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

--

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

Tariq,

Thanks for enquiring about new ISA extension coordination with the Smstateen extension that was ratified last year.

The first thing to note is that the primary purpose of and motivation for Smstateen is to close off covert communication channels created by new extensions that add new arch state that needs to be context switched (but may not be context switched by an unaware OS or hypervisor).  (A secondary usage of Smstateen is for rare cases of extensions that are not backward compatible and need to be disablable for backward compatibility.)  This extension is not intended to provide a general mechanism for disabling arch extensions.  Many extensions don't need such and one that does would define its own appropriate mechanism based on the nature of the extension.  (Smepmp, for example, implicitly provides practical backward compatibility by how it defines the semantics of the new CSR bits that it introduces - such that new or modified functionality only becomes active when explicitly enabled by software.)

The second thing to note is that Smstateen, as ratified last year, comprehended the few other extensions that were ratified last year that needed Smstateen support.  Going forward, a new ISA extension that fits the preceding primary and secondary Smstateen use cases should specify any new bit(s) it adds to the *stateenX CSRs.  Then, once it is ratified, this should be moved into the Smstateen chapter that will exist in the Priv spec (when the Smstateen extension itself is merged into the Priv spec - tbd whether before or after Priv conversion to adoc).  The post-ratified ISA extension spec should retain a short mention of and cross reference to the added Smstateen bit(s).

This will put all the new arch functionality introduced by a new ISA extension into one spec document for use during TG reviews, Arch Review, Tech Chairs/TSC/BoD votes, and public review.  Then the added Smstateen detailed functionality can be moved into the Smstateen chapter after ratification.

Regarding Zcmt in particular (which is due to be ratified this year I believe), it seems like adding Smstateen functionality might be necessary only if Zcmt breaks backward compatibility by redefining existing defined opcodes.  I don't remember if that applies here.  (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.)

Greg

On Mon, May 16, 2022 at 6:58 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:

In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.

As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:

Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks

Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:

Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).

There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.

https://github.com/riscv/riscv-code-size-reduction/issues/160

Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

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

--

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

In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.

As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:

Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks

Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:

Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).

There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.

https://github.com/riscv/riscv-code-size-reduction/issues/160

Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

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

--

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

In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.

As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:

Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks

Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:

Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).

There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.

https://github.com/riscv/riscv-code-size-reduction/issues/160

Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

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

--

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