4976 - recommend that operand order be fixed

I've been allowing operands in any order just because it simplifies implementation.
I don't actually rely on this flexibility; all the .subx programs in this
repo consistently use a single ordering.

Why is a hard-coded canonical order hard to implement? The order that seems
most logical to me is complicated by the "reg" bits in the ModR/M byte:

- In instructions that interpret it as an `/r32` operand, it needs to be
  deemphasized because it refers to a different argument of the instruction
  than the `/mod`, `/rm32`, `/base`, `/index` and `/scale` operands that
  capture the bulk of instruction decoding complexity and so should be
  emphasized. `/r32` can also be unused, which strengthens the case for
  deemphasizing it.

- In instructions that interpret the "reg" bits as a `/subop` operand,
  it should be colocated with the opcode because it performs the same function:
  specifying the *operation* the instruction performs.

In both cases, the bits in the `reg` bitfield are conceptually unrelated
to the other bitfields in the same byte. But they sometimes want to be
close to the opcode bytes on the left, and at other times need to be deemphasized
rightward. Fixing both these possibilities seems complicated and stateful,
particularly since all operands are optional in general. On the other hand,
just pulling operands you need to create each byte, regardless of where
in the instruction they occur, that's nicely stateless.

0 files changed, 0 insertions, 0 deletions