Post-Ratification Clarification: Dependency from Zve32x to Zicsr

[a4lg]

All vector extension subsets depend on several CSRs including vl, vstart, vxsat etc...

My request is, as this fact suggests that the all vector extensions (V and Zve*) depend on the Zicsr extension, to clarify that at least the Zve32x extension (and optionally, Zve64x and/or all vector subsets) depends on the Zicsr extension.

This request to the Zve32x extension is based on the facts:

1. Zve*f and Zve*d extensions depend on F or Zfinx / D or Zdinx extensions (respectively) and indirectly depends on the Zicsr extension already.
2. The same will apply to V since V depends on D (existing dependency chain: V → D → F → Zicsr).
3. Existing toolchains assume that Zve64x (integer only but supports EEW=8,16,32,64) implies Zve32x (integer only, supports EEW=8,16,32) so dependency from Zve32x is important.

So, clarifying dependency Zve32x → Zicsr is sufficient (though Zve64x → Zicsr or V / Zve* → Zicsr is helpful).

There's other related links:

1. Zicntr / Zihpm extensions (in the ISA Manual) have dependencies to Zicsr.
2. I requested some draft extensions to clarify that an extension with CSR depends on the Zicsr extension as follows:
   • Zjpm Proposal: Add dependency to Zicsr riscv-j-extension#17
   • Proposal: Add dependency to Zicsr riscv-cfi#14
3. I requested clarification to existing ratified specifications:
   • Post-Ratification Clarification: Dependency from Zkr to Zicsr riscv-crypto#350
   • Post-Ratification Clarification: Dependency from Zve32x to Zicsr #908

[asb]

Just my 2c from an LLVM perspective. LLVM implements this dependency, as given these extensions introduce CSRs it seems logically Zicsr must be implied. I'm in favour of stating this dependency explicitly in the text - it makes it easier for those implementing tooling to do the right thing.

[a4lg]

@asb I'm happy to hear that LLVM implements that dependency. We (at GNU side) quickly concluded we can imply Zicsr from privilege extensions (as the privileged architecture itself depends on the Zicsr extension) but we couldn't in unprivileged ones (yes, logically there should be an implicit dependency but I could not convince some of the members).

In either case, stating this dependency explicitly in the text would be nice.

[nick-knight]

This is something that I've never quite understood. The ISA spec says

RISC-V defines a separate address space of 4096 Control and Status registers associated with each
hart. [Zicsr] defines the full set of CSR instructions that operate on these CSRs.

(Vol I:11, reiterated in Vol II:2.1)

which suggests to me that the CSR space exists regardless of Zicsr, and Zicsr simply adds the csr* instructions. (An implementation could provide other means of accessing CSRs.) As to why F mandates Zicsr, my best guess was that it was an effort to avoid software fragmentation due to non-standard (non-Zicsr) CSR access mechanisms.

However, I could be misreading the ISA spec, which seems to happen more often than not.

[aswaterman]

F implies Zicsr so that there's a standard way of accessing fcsr. It's true in principle that there could be an implementation-defined means to access the fcsr, but it's not terribly interesting for the purposes of standard software.

For similar reasons, Zve32x should imply Zicsr.

[a4lg]

Thanks!