Make instr_dict.yaml more detailed

[Vinayakamk]

consider this instr_dict.yaml snippet of making extention rv*_c
it has this
c_sw:
encoding: '----------------110-----------00'
extension:

• rv_c
  mask: '0xe003'
  match: '0xc000'
  variable_fields:
• rs1_p
• rs2_p
• c_uimm7lo
• c_uimm7hi

i wish it would be more detailed and clear if the variable fields are bifurcated into immediate(or args ) and register fields like

args_field:

• c_uimm7lo

• c_uimm7hi
  register_field:

  • rs1_p
  • rs2_p

  this will be helpfull to analyse and know registers of the instructions of such type like
  "rv.zcmp":
  "cm.mva01s c_sreg1 c_sreg2 1..0=2 15..13=5 12..10=3 6..5=3",
  "cm.mvsa01 c_sreg1 c_sreg2 1..0=2 15..13=5 12..10=3 6..5=1",
  "cm.popret c_rlist c_spimm 1..0=2 15..13=5 12..8=0x1E",
  "cm.pop c_rlist c_spimm 1..0=2 15..13=5 12..8=0x1A",
  "cm.push c_rlist c_spimm 1..0=2 15..13=5 12..8=0x18",
  "cm.popretz c_rlist c_spimm 1..0=2 15..13=5 12..8=0x1C"

  since arg_lut.csv contains both register and imm fields,it is not clear to know what are registers and imm
  
  if there is the way to know it ,kindly let me know!
  thanks
  

[keys-i]

Thank you for your suggestion! Separating the variable fields into args_field (for immediates) and register_field is a great idea. It would make the instr_dict.yaml more readable and easier to analyze, especially for complex instructions like those in the "rv.zcmp" extension.

Currently, arg_lut.csv includes both registers and immediate fields, which can be confusing. Your proposed structure would clarify this by clearly distinguishing between the two. Here's an example:

c_sw:
  encoding: '----------------110-----------00'
  extension: rv_c
  mask: '0xe003'
  match: '0xc000'
  args_field:
    - c_uimm7lo
    - c_uimm7hi
  register_field:
    - rs1_p
    - rs2_p

This adjustment would improve clarity and usability. If there’s an existing method to differentiate these fields, please share, but I think this change would be a helpful improvement. Thanks again for the suggestion!

[ethindp]

Is it me or is the comment by @keys-i AI generated? It certainly looks like it.

With respect to detail, I think this might be pretty useful, although we should probably add metadata about immediates; for instance, it would be useful for code generation to be able to know at the decode stage whether an immediate is signed or unsigned. This would primarily be useful in compile-time evaluation in emulators and such, where you might wish to trap if a function is not implemented matching the given set of parameters and types, or call it otherwise.

[aswaterman]

Given ongoing work on Unified DB at RVIA, I'd rather not modify the metadata format in riscv-opcodes, as it is likely redundant and will probably create extra work. (cc @dhower-qc)