Zcmt → Zicsr dependency?

[a4lg]

As the Zcmt extension adds jvt CSR (URW, 0x17), I think it's required to note that the Zcmt extension depends on Zicsr as well as Zca.

This is important also because the jvt CSR is an unprivileged CSR (so we cannot assume the existence of the privileged architecture, which requires Zicsr).

[a4lg]

This is a duplicate of #155 (I didn't notice that when I opened this) but I could not find an actual fix for #155 (despite that this issues is closed as fixed).

[tariqkurd-repo]

It's implicit. Every CSR in the priv spec doesn't say "needs Zicsr" - there's just one statement saying Zicsr is needed for all of them.

If Zcmt is implemented then JVT must also be implemented, but can contain a read-only value.

In the JVT spec, which implicitly requires Zicsr.

is that ok?

[a4lg]

For privileged specifications, it's okay.

For unprivileged specifications, the position is not that clear. To be clear, recent draft of the RISC-V ISA Manual, Part I (unprivileged part) is doing the opposite. For instance, quoting the latest manual (draft):

Chapter 12 “Zicntr” and “Zihpm” Counters

...
The Zicntr extension depends on the Zicsr extension.
...
The Zihpm extension depends on the Zicsr extension.

I'm happy if Zicsr dependency is implicit as you said (because we can avoid existing problems like in Zkr (a part of cryptography extensions) and Zve32x/Zve64x (both vector subset without floating point arithmetic support)) but... since the official position is not so clear, I still request the changes (I'm not closing this yet).

[tariqkurd-repo]

@aswaterman I'm sure this came up before and I didn't list Zicsr in the Zcmt spec for the reason listed above. Can you comment on @a4lg 's concerns?

[a4lg]

@tariqkurd-repo Interesting. Yes, I need some proper clarification but implicit Zicsr dependency is okay for me (see below).

Further Context

Similar discussion came up when I tried to implement implicit implication rule Zkr / Zve32x → Zicsr etc... to GNU Binutils.

• https://sourceware.org/pipermail/binutils/2022-September/122757.html (PATCH v1)
• https://sourceware.org/pipermail/binutils/2022-September/122761.html (PATCH v2)
• https://sourceware.org/pipermail/binutils/2022-September/122766.html (comment by @Nelson1225)
• https://sourceware.org/pipermail/binutils/2022-September/122768.html (comment by @kito-cheng)

At the time of PATCH v1 submission, I expected implicit Zicsr rule as @tariqkurd-repo described. But further investigation made the situation unclear on unprivileged extensions and we had to temporally conclude that it's not safe to assume that implication rule on unprivileged extensions.

So, for me, both options are okay as long as clarified somewhere:

1. There is general implicit dependencies (all unprivileged extensions with CSR definitions/uses → Zicsr)
2. There is (or must be) an explicit dependency (likewise, or at least Zcmt → Zicsr)

[aswaterman]

Please just include the following sentence in the Zcmt spec: "The Zcmt extension depends on the Zicsr extension."

This is what we do for e.g. the F extension. It means that listing only Zcmt in the ISA string is sufficient; Zicsr is implicitly present if Zcmt is present.

[tariqkurd-repo]

so elsewhere we're using the phrase (e.g.) Zcmt requires Zca, as oppose to Zcmt depends on Zicsr, so the updated adoc text is:

Zcmt requires the <<Zca>> and Zicsr extensions.

do you take requires and depends on to have the same meaning here?

thisi is what I've put in v1.0.0-RC5.3 - but if the relationship between Zcmt and Zicsr and Zcmt and Zca are different then I'd like to be clear about exactly what that means

Tariq

[aswaterman]

I'm not trying to suggest the relationship between Zcmt and Zca differs from the relationship between Zcmt and Zicsr. I'm just quoting the ratified spec. We should use the same language for all of the above, IMO.