Use fd/fs# for floating point operands

[ghghost]

The data in riscv-opcodes-master is almost exactly what I need to generate the instruction and operand parsing code for my work on binary code modeling and analysis, except for one thing: both the integer and floating point register fields are named "rs1", "rs2", "rd". The vector register fields are already named "vs1" etc., and if the floating point registers were changed to "fs1" etc., this data would include everything needed for both bit-level parsing and operand identification.

[aswaterman]

If you want to contribute that, we'd be willing to accept it. It won't be a totally trivial exercise, because FP registers show up as arguments all over the place (e.g. as scalar arguments to vector instructions with a vf prefix). As a sanity check, you'll want to make sure all of the various outputs (including e.g. the LaTeX) are unchanged by your changes.

For a moment I was wondering what the implications are for Zfinx, but I think that's fine: anything consuming this metadata can simply remap e.g. fs1 to rs1 when using Zfinx instead of F.

[ghghost]

Yes, it's a sizable job. I believe the following ratified modules are affected: rv_c_d, rv_d, rv_d_zfh, rv_f, rv_q, rv_q_zfh, rv_v; rv_zfh; rv32_c_f; rv64_d, rv64_f, rv64_q; rv64_zfh. And the following unratified modules: rv_d_zfa, rv_f_zfa, rv_q_zfa; rv_zfbfmin, rv_zfh_zfa, rv_zvfbfmin, rv_zvfbfwma2; rv32_d_zfa; rv64_q_zfa. In addition, new entries will be needed in constants.py, and some minor additions to README.md to alert future editors.

Regarding the LaTeX output, I'm inferring that fields identified as fd/fs# should output as rd/rs# in the LaTeX et al, for compatibility with existing consumers of those outputs that don't read the metadata files directly. Is that correct?

[aswaterman]

Right, as a first step, we'd want to make sure the LaTeX is bitwise identical. Whether to later change what gets printed in the specs would be a separate discussion and separate PR.

[NyembeziIMG]

Has any progress been made on this issue? We are interested in the solution and would be willing to contribute/collaborate.

[aswaterman]

No progress, but we’re willing to accept a PR if it doesn’t change any of the outputs (i.e. you’ll want to make sure they’re all bitwise identical).

[NyembeziIMG]

Many thanks for the feedback @aswaterman.

Makes sense. We will schedule work on our side for this and aim to contribute as it should a useful feature for more than one use case.