Skip to content

riscv_fix_csr_access_and_imply

Jump to bottom
Tsukasa OI edited this page Nov 26, 2022 · 12 revisions

RISC-V: Fix CSR accessibility and implications

Issue Solved

Background

While I'm reorganizing b-ext* and k-ext* tests (to make sure that they are able to be removed since there are neither B nor K extensions), I found something interesting.

If we assemble a file with csrr a0, seed (uses seed CSR from the Zkr extension) with -march=rv32i_zkr, it causes an error to require Zicsr. Yes, current GNU Binutils does not imply Zicsr from Zkr so that adding Zkr extension alone is not enough to access corresponding CSRs (current version requires an option like -march=rv32i_zicsr_zkr).

k-ext.d does not give Zicsr either (and does not test the seed CSR) and adding the line csrr a0, seed to the corresponding test file (k-ext.s) resulted the same.

In General

That means something. If an extension adds CSR(s), we should imply Zicsr from that extension (just like F). So, we have to imply Zicsr from following extensions:

  • H
  • Zkr
  • Zve32x (I'll talk later)
  • Smstateen
  • Sscofpmf
  • Sstc

Zkr is fixed in PATCH 2/3 and H and S* are fixed in PATCH 3/3. The only remaining extension is Zve32x but I need to talk more to explain actual changes (specific to vectors) in PATCH 1/3.

Vector-specific Issue

On the current version of GNU Binutils, CSRs with CSR_CLASS_V means they require the V extension. However, there are a few vector subextensions that implement vector subsets (intended for embedded processors).

  • Zve64d (superset of Zve64f)
  • Zve64f (superset of Zve32f and Zve64x)
  • Zve64x (superset of Zve32x)
  • Zve32f (superset of Zve32x)
  • Zve32x

Graph: Dependency graph of some vector/FP extensions

+-------> D ---+----> F -----> Zicsr
|         ^    |      ^
|         |    /      |
V ---> Zve64d ---> Zve64f ---> Zve64x
               \      |           |
               |      V           V
               +-- Zve32f ---> Zve32x
                                  |
                                  |
                                  +---> (Zicsr [added in PATCH 1/3])

Actual Vector CSR Requirements

They also require general purpose vector CSRs (vstart, vl, vtype and vlenb). So, corresponding CSR_CLASS_V with the V extension is inappropriate (they should require Zve32x instead, the minimum vector subset).

Remaining CSRs are:

  • vxsat
  • vxrm
  • vcsr

They are related to fixed-point arithmetic and 18.2 "Zve*: Vector Extensions for Embedded Processors" says:

All Zve* extensions support all vector fixed-point arithmetic instructions (Vector Fixed-Point Arithmetic Instructions), except that vsmul.vv and vsmul.vx are not supported for EEW=64 in Zve64*.

So, their minimum requirement shall be also Zve32x, not V.

As a consequence, we can conclude that changing requirements of CSR_CLASS_V from V to Zve32x is sufficient to avoid CSR accessibility warnings.

Actual Implications (and its limitation)

Also, Zve32x must imply Zicsr (just like the rest) to avoid CSR instruction errors. This is only effective on Zve32x and Zve64x because, for instance, Zve32f implies F and F implies Zicsr (see the graph above).

I didn't rename CSR_CLASS_V to CSR_CLASS_ZVE32X because the name gets difficult and there's already INSN_CLASS_V (effectively requires Zve32x with some exceptions).

Clone this wiki locally