Skip to content

riscv_common_regpair

Jump to bottom
Tsukasa OI edited this page Oct 1, 2022 · 6 revisions

RISC-V: Implement common register pair framework

Related

Feature Description

I might able to provide another proposal not only for Zfinx fixes.

Register pairs using GPRs are not exclusive to Zdinx and Zqinx. We currently expect that following extensions use register pairs:

  • Zdinx (ratified)
  • Zqinx (once proposed but not ratified)
  • Zbpbo (a part of 'P'-extension proposal)
    Only used for instruction aliases WEXT and WEXTI.
  • Zpsfoperand (a part of 'P'-extension proposal)
    For instance, https://github.com/riscvarchive/riscv-binutils-gdb/pull/257 uses "nds_rdp", "nds_rsp" and "nds_rtp" for register pair operands.

Due to this, if we have a common framework to handle register pairs, they will be a lot easier. But, as long as following statement is acceptable:

If an invalid/reserved encoding is disassembled, it might be disassembled as an instruction with invalid operands.

Take for example, RVE.

If an instruction (for use for RV32E environment) use the encoding add x14, x15, x16, x16 is an invalid GPR for RVE.

The best disassembler result would be .4byte 0x1078733, meaning an instruction is not recognized. However, this resolution is sometimes hard and forces to use some buffering before printing.

The second best solution would be... add x14, x15, invalid16 or something like that. invalid16 is used so that the encoding is not valid on the current situation (e.g. ELF attributes meaning RV32E). Note that similar solution unknown is already used by the RISC-V disassembler.

.insn 0x0107e753

This is a invalid encoding of fadd.s fa4, fa5, fa6 with a reserved rounding mode. Current GNU Binutils disassembles this instruction as:

fadd.s fa4,fa5,fa6,unknown

unknown here makes sense. Extending this idea is a viable solution.

So, my big question is, is it acceptable to apply and extend this idea? Here's only a part of such cases:

  • RVE: invalid register number
  • Register Pairs (Zdinx, Zqinx, Zbpbo and Zpsfoperand): invalid register number
  • Shift amount (SHAMT): equals to or greater than XLEN

If the idea above is acceptable for RISC-V GNU toolchain developers, this patchset provides common framework for register pairs all for Zdinx, Zqinx, Zbpbo and Zpsfoperand.

Format

  1. 'l' (stands for length)
  2. One of the following:
    • '1' for 32-bit data (or less; though redundant, makes code readable)
    • '2' for 64-bit data (RV32: 2 registers)
    • '4' for 128-bit data (RV32: 4 registers, RV64: 2 registers)
  3. One of the following (note that a GPR is expected here, even on 'r' and 'u'):
    • 'd' for RD
    • 's' for RS1
    • 't' for RS2
    • 'r' for RS3
    • 'u' for RS1 and RS2 (where RS1 == RS2)
    • To be added later: 'F' (for Zbpbo WEXT aliases)
      for RS1 and RS3 (RV32 "l2F" only; RS1 is even and RS3==RS1+1)

For instance, "l2d" means a 64-bit width destination register operand. On RV32, it would require a register pair and the register number must be even. On RV64, it represents a GPR and no alignment requirements.

When assembling, it indirectly raises an error for an invalid register.

When disassembling, it once accepts all register numbers but the output depends on whether the register number is valid for register pair requirements:

  • If valid, regular GPR operand is printed.
    (Style: dis_style_register)
  • If not, "invalid%d" (where %d is the register number) is printed.
    (Style: dis_style_text)
Clone this wiki locally