search

riscv / riscv-opcodes

RISC-V Opcodes
https://riscv.org/
BSD 3-Clause "New" or "Revised" License
696 stars 303 forks source link

Use fd/fs# for floating point operands #190

Open ghghost opened 1 year ago

ghghost commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 4 months ago

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

aswaterman commented 4 months ago

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 commented 4 months ago

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.