.CIL File Format – Opcode map

Introduction

Every CIL opcode, in order, with the facts the runtime library’s opcode table records about it. The first section is the one-byte opcodes; the second the two-byte ones, which start with FE. The columns are:

• Operand – what follows the opcode (the kinds are on the overview).
• Pops and Pushes – the evaluation-stack behaviour: Pop0 nothing, Pop1 one value of any kind, Popi an integer (an address or an int32), Popref an object reference, and combinations such as Popref_popi (an array and an index) and Pop1_pop1 (two values, the later one on top); Varpop and Varpush depend on a signature. Push1 is a value of any kind, Pushi an integer, Pushi8 an int64, Pushr4 and Pushr8 floating point, Pushref an object reference, Push1_push1 two copies.
• Flow – how control continues: Next to the next instruction, Branch to a target only, Cond_Branch to a target or the next instruction, Call into a method and back, Return, Throw, Break (to the debugger) and Meta (a prefix: it only qualifies the next instruction).
• Type – Primitive for an instruction with its own meaning, Macro for a short form of another instruction, Objmodel for the object-model instructions, Prefix for a prefix and Nternal for the reserved bytes (the spelling is the library’s).

The names link to the entry on the instruction’s page. Unused single-byte values (24, 77, 78, A6 to B2, BB to C1, C4, C5, C7 to CF, E1 to F7) and the unused values after FE (08, 10, 1B and everything from 1F) are not opcodes; the explorer decodes such a byte as a one-byte (or, after FE, two-byte) .byte item and reports it.

One-byte opcodes

Two-byte opcodes (first byte FE)

Not described

Known, not yet covered

• Per-runtime acceptance: the table is the runtime library’s (checked against it, field by field, plus no. from the specification); which runtime version accepts which opcode was not checked.

Unknown

• None found.

Links