Assembly schema

[Paul Clarke (ThinkOpenly)]

This discussion is about how to represent the assembly syntax for instructions. Example:

    mnemonic [operand1, ...]

Operands can be indexes into various register files, integer values, base+offset "integer_offset(base_general_purpose_register_file_index)", and various other special cases.

Currently the assembly syntax is represented simply as a string showing the comma-separated operands using various ad-hoc conventions for register file, source/destination, various attributes of integer values ("immediates") (signedness, class, etc.), etc.

As an example, from "store word" ("sw"):

xs2, imm(xs1)

1. "xs2"
   • "x": general purpose register file
   • "s": source value (read-only)
2. "imm(xs1)"
   • "imm": immediate (integer value). Note that signedness is not clearly specified.
   • "xs1"
     • "x": general purpose register file
     • "s": source value (read-only)
   • "imm(xs1)" represents the value of general purpose register "xs1" + the integer value

If we restrict the term "operand" to just those elements in a comma-separated list, then we need to consider what those elements can be, and the various associated and independent attributes:

• register
  • register file (and associated range of valid indexes)
  • register file index
  • dereferenced? "(xs1)"
  • with offset? "offset(xs1)" (with acceptable values)
  • source and/or destination (can be both)
  • mnemonic / alias translation to index ("a0" == "x10" == index 10, 0-based)
  • register pair?
  • optional?
  • the "* in X" extensions overlay the floating-point register file on top of the general purpose register file. (Does that need to be handled here? ZdinxRV32 is particularly interesting.)
  • some instructions have multiple syntaxes (see VSETVLI/VSETIVLI)
• immediate
  • range (including signedness, acceptable values)
  • name (for human-readable output)
• special cases
  • floating-point rounding mode
  • FENCE scope(s)
  • PUSH/POP register list
  • floating-point immediate

Adjacent, there needs to be an explicitly defined mapping from operands to opcode fields and vice-versa.

PR #1435 and PR #1527 are taking steps to address this representation. I'm opening this "discussion" to maybe talk through the approaches and make sure we end up with a reasonable complete and robust solution.

(Explicitly inviting Derek Hower (@dhower-qc) and Sam Elliott (@lenary), but anyone is welcome with constructive comments.)

[Paul Clarke (ThinkOpenly)]

Currently, the gist of #1527 is to create a new instruction attribute, "operands" which is simply an array of the various operand types (register, immediate, and the other less-common types). Each operand will support/require attributes to fully define it. (Not everything listed above is there yet. This allows the assembly syntax to be formally defined, avoiding heuristics and conventions.

It does not attempt to support linker symbols, nor does it include anything about operand-field mappings.

[Derek Hower (dhower-qc)]

If we are mucking with the assembly string, I suggest we also enclose all operand references in {} (or something) to differentiate them other, non-special text