Skip to content

riscv_dis_support_special_encodings

Jump to bottom
Tsukasa OI edited this page Nov 19, 2022 · 5 revisions

Disassembler: Support special (non-standard) encodings

Conflicts With

Issues Solved

1. Rounding Mode on Widening Instructions

There are some instructions that their operation is not mathematically affected by rm (rounding mode) bits.

  • fcvt.s.h
  • fcvt.d.h
  • fcvt.q.h
  • fcvt.d.w
  • fcvt.d.wu
  • fcvt.d.s
  • fcvt.q.w
  • fcvt.q.wu
  • fcvt.q.s
  • fcvt.q.d
  • fcvt.q.l (RV64 only)
  • fcvt.q.lu (RV64 only)

On such instructions, only RNE-rounding variant (with rm bits of 0b000) are correctly disassembled (except fcvt.q.l and fcvt.q.lu, that supported rounding mode operand in the past). While RNE is the default (and preferred) rounding mode on such instructions, all other valid variants are disassembled as invalid instructions.

S Pawan Kumar (@pawks) proposed a patch by adding instruction variants with rounding modes. I'm okay with his patch but I have a small concern whether it may be too aggressive.

So, I chose rather conservative approach first. It contains complete disassembler support and stub assembler support (which generates error when used). Bigger disassembler problem is resolved only with this and we can easily modify the code to support @pawks' proposal.

Current Behavior

Disassembler

  • no-aliases disassembler option is required to decode additional (non-default) rounding modes.

Assembler

  • On fcvt.q.l and fcvt.q.lu, show a warning when a rounding mode is specified.
  • On other instructions (listed above), show an error.

Request for Comments (RFC)

It reserves two additional operand types !M and !m (reserving one-character operand types seemed too much). Is it okay?

2. Special (non-standard) encodings of FENCE-like instructions

Quoting the ISA Manual,

2.7 Memory Ordering Instructions

... The unused fields in the FENCE instructions—rs1 and rd—are reserved for finer-grain fences in future extensions. For forward compatibility, base implementations shall ignore these fields, and standard software shall zero these fields. Likewise, many fm and predecessor/successor set settings in Table 2.2 are also reserved for future use. Base implementations shall treat all such reserved configurations as normal fences with fm=0000, and standard software shall use only non-reserved configurations.

Chapter 3: “Zifencei” Instruction-Fetch Fence, Version 2.0

... The unused fields in the FENCE.I instruction, imm[11:0], rs1, and rd, are reserved for finer-grain fences in future extensions. For forward compatibility, base implementations shall ignore these fields, and standard software shall zero these fields.

Those reserved fields/combinations are supposed to be zero for compatibility still can be valid as FENCE-like instructions. Note that there's no useful if we supported those fields on the assembler.

However, GNU Binutils' disassembler can be treated as a base implementation and this patchset tries to simulate the behavior described in the ISA Manual.

To support this behavior, I added ~ special operand modifier. Any fields after ~ are ignored but considered used by the assembler. This is required because just removing MASK_RD (for example) from mask value of FENCE-like instructions results in an internal error (because rd field is not used).

Behavior

On FENCE.I, non-zero rd and rs1 are ignored and printed as a fence.i instruction.

On FENCE,

  • Non-zero rd, non-zero rs1 are ignored.
  • Reserved fm+pred+succ combinations are considered regular fence (fm is ignored but pred and succ are respected).
  • Print reserved fence.tso as a fence.tso instruction (with no operands).
  • Print reserved fence as a fence instruction with two operands.
Clone this wiki locally