Module op 

The hundred and one opcodes, and what each one makes of the four fields.

One opcode per concrete operation

Inst’s own doc argues that “the instruction set describes families, not cases” — one Arith, not one per numeric type — and that argument is about the language growing a concept. The bytecode grows none by enumerating members that already exist, and it removes a nested dispatch by doing so. ADR 0041 decides the enumeration:

• Inst::Arith becomes ten, Num × ArithOp;
• Inst::Cmp becomes thirty-six, Compare × CmpOp;
• Inst::ArithImm five and Inst::CmpImm six, the operator alone;
• Inst::Neg two, Convert two;
• Inst::Alloc three, one per Len form, so no discriminant is stored anywhere.

The cross products are generated, not hand-picked

Op::all is the enumeration and an opcode number is a position in it. Nothing here lists a hundred numbers, and nothing lists which operator pairs with which comparison: crate::verify already constrains which Reprs a Compare admits and does not constrain the pairing, so a hand-picked table would be a second and weaker copy of the type rules, living in the encoder. An opcode the lowering never emits costs one number out of 256 and one row of a generated table; a rule about which pairs are legal costs a place for two copies to disagree.

Op::number computes the same number by arithmetic, so that it is not a search, and Op::from_number inverts it through a table built from Op::all — one direction derived from the other rather than two lists to keep in step. The tests below pin all three against each other.

Structs

Fields

What an opcode makes of the four fields.

Enums

Half

What one 32-bit half of a payload holds.

Op

One concrete operation.

Operand

Which of a, b and c an opcode uses, and for what.

Payload

What the payload’s eight bytes are.

Constants

ANY

An operand whose Repr the opcode does not constrain. See Operand::Word.

OPCODES

How many opcodes are defined, out of the 256 an opcode byte can name.