The Master ISA Encoding Appendix

This is the byte-level opcode-encoding lookup for the Vision-Q7 Cairo (ncore2gp) FLIX/VLIW ISA — the master synthesis of the per-slot mnemonic sweep and the per-instruction reference. It is the reference an implementer keeps open while writing an assembler: for any of the 1534 shipped mnemonics it gives the encoding row — format · slot · unit · iclass · opcode-selector CONST · template immediate — plus the 14-format / 46-slot / 7-length framing tables and the encode-thunk ABI (C7 07 imm32 [C7 47 04 imm32] C3) the per-instruction batches (B01–B30) expand from.

This page is a consolidation, not a re-derivation: it owns the lookup matrix and the framing tables; the deep mechanism lives in its four sources, which it cross-links and stays numerically consistent with:

• The FLIX VLIW Encoding — the 14-format / 46-slot grid, the format_decoder/length_decoder bodies, the per-slot placement census (§6.3) this page tallies.
• The libisa Table Schema & Codec ABI — the byte layout of every table (opcodedefs[], opcodes[], slots[], fields[]) and the four-layer codec.
• The Canonical ISA Decode Model (libisa-core) — the formats → slots → opcodes → iclasses → operands → fields object model and the decode loop.
• ISA Coverage & the 1534/1607/12642 Tally — the certified 1534/12569 denominator this appendix inherits, and the +73 fold.
• The TIE Database & Four Independent ISA Sources — the authoring superset (1607/12642) the runtime tables fold from, and the four-source agreement.

The byte-level row expansions live in the per-instruction reference (template & partition, then b01-vec-alu-int.md … b30-appendix-p.md); this appendix is the lookup those batches compress.

Everything below is read directly out of the shipped Tensilica libisa config library libisa-core.so (ncore2gp/config/, sha256 8fe68bf4…f143e451, 9 690 712 bytes, ELF64 x86-64, not stripped, 45 058 symbols), re-grounded against the binary this pass via nm, objdump -d, readelf -SW, and a direct byte-parse of opcodes[]/opcodedefs[] — never a decompile grep. The value side is libfiss-base.so (sha256 260b110c…, 12 330 016 B). The device-native xtensa-elf-objdump/xtensa-elf-as (XTENSA_CORE=ncore2gp) serve as an independent encode/decode oracle.

Confidence tags follow the Confidence & Walls Model: OBSERVED = a byte/immediate/symbol read from the shipped binary (or computed by executing the shipped simulator); INFERRED = reasoned over OBSERVED facts; CARRIED = re-used at a cited report's confidence; crossed with HIGH/MED/LOW. Callouts: QUIRK (counter-intuitive but real), GOTCHA (a reimplementation trap), CORRECTION (overturns a naive reading), NOTE (orienting context).

GOTCHA — every count on this page is grounded in a num_* getter immediate or an nm | rg -c symbol-family population, never a decompile grep. Counting the Opcode_*/Field_*/Slot_* families in the IDA/Hex-Rays decompile inflates 2–12× (one thunk is referenced from many call sites and counted once per reference). The binary .symtab is the arbiter. Where this page states a count, the witness is named in the row.

GOTCHA — .data.rel.ro / .data VMA↔file delta is 0x200000 for this binary; .text / .rodata are VMA == file-offset. The encode/field/slot thunks live in .text (0x312c10, delta 0) and resolve direct; the tables (opcodes @ 0x6ce6c0, opcodedefs @ 0x6e9640) live in .data.rel.ro (VMA 0x67bb00 → file 0x47bb00). Do not carry over libtpu.so's 0x400000 .data delta — that is a different binary (readelf -SW, re-read this pass: .text 0x312c10/0x312c10; .rodata 0x3b6e40/0x3b6e40; .data.rel.ro 0x67bb00/0x47bb00; .data 0x764040/0x564040). libisa-core.so is in extracted/ (gitignored; reach with an absolute path or fd --no-ignore).

1. The encoding-key facts in one block

Every dimension this appendix indexes, with its binary witness — re-read this pass.

CORRECTION — num_operands is 232, not the Cadence enum's 1517. The Cadence xtensa-modules.c OPERAND_* enum is 1517 (it enumerates implicit/state operands too); the shipped binary's operands[] table is 232 codec operands. Pin 232 for the binary; 1517 is [HIGH/CARRIED] and never indexes anything in this .so. Likewise num_operands ≠ num_fields (232 vs 3237): a field is a per-(name × slot) bit-window, an operand is a per-codec value↔field tuple; the 3237 fields recur the same logical field once per slot.

2. The format / slot / length framing tables

These three tables are the framing an encoder lays before it deposits any opcode-selector bits. They are reproduced verbatim from the FLIX encoding page and reconciled to it cell-for-cell; the mechanism (the format_decoder mask ladder, the length_table index math) lives there and is not duplicated here.

2.1 The 14 formats (formats[] @ 0x6cd980, stride 24)

{ char *name; int length; void(*encode)(uint32_t*) }. op0 = byte0[3:0]; b3lo = byte3[3:0]; the signature is the first 4 template bytes the Format_<F>_encode stub lays.

Slot-count census: 1+1+1+4+5+4+4+5+4+4+4+3+2+4 = 46 = num_slots. There is no F5/F8/F9/F10. The two 5-slot formats are F3 (idx 7) and F11 (idx 4). F4 (dual-Ld) and F11 carry no dedicated store slot.

GOTCHA — drive everything off the format name, not its table index. In formats[], idx 4 = F11, idx 7 = F3, idx 11/12/13 = N1/N2/N0 (N0 is last). The Fn numbering has real gaps and the index order is not the name order.

2.2 The length classes (length_table[256] @ 0x3d4100, .rodata, VMA==file)

length_decoder forms idx = ((byte3 << 4) & 0xFF) | (byte0 & 0xF) and indexes the 256-entry int32 table. Only the op0 == 0xF column varies with b3lo:

256-cell value census {3:128, 2:96, 16:22, 8:8, −1:2} — 7 distinct outcome classes, but only 4 distinct byte-sizes {2,3,8,16} a sweep pointer ever advances by (the −1 is a hard illegal, not a size). [HIGH/OBSERVED]

CORRECTION — the static XCHAL_BYTE0_FORMAT_LENGTHS macro flattens op0==0xF to a constant 8 and will desync you. The shipped runtime length_decoder also reads byte3.low4, so a real op0==0xF word decodes to 8, 16, or illegal. The binary length_table is authoritative.

2.3 The 46-slot roster (slots[] @ 0x6cdb00, stride 48)

{ char *name; char *format; char *nop; int position; void(*get); void(*set) }. bitoff = the slot field's start bit; width = decoded slot-word bit-length ([MED/INFERRED], machine-code-emulated, ±1–2 bits on scattered slots); pos = sequential issue index; get from slots[i]. All 46 names/positions/get-addresses/<bitoff> tokens re-read from slots[] + the Slot_*_get symtab this pass; every cell agrees.

Functional-unit vocabulary: whole (the whole base/density instruction — x24/x16a/x16b s0); ldst (combined load/store); ldstalu (load/store + ALU fused — F1 s0 only); ld (load-only); mul (multiply); alu (arithmetic/logic); none (NOP-only placeholder, 1–3 bit).

GOTCHA — three slot rules a reimplementer must internalize. (1) bitoff ≠ slots[].position — position is the sequential issue index 0..N-1; the real bundle offset lives in the get-thunk's <bitoff> token / scatter body. (2) width ≠ next_offset − offset — above its low byte each slot scatters into high bits, so the gather body is authoritative. (3) Issue order is not bit order — e.g. F3's S4 ALU sits at bit 24, before S2 Mul (28) and S3 ALU (33). Every s0 starts at bit 4 because bits [3:0] are always the op0 selector.

3. The encode-thunk ABI — C7 07 imm32 [C7 47 04 imm32] C3

Every Opcode_<mnem>_Slot_<slot>_encode is a tiny .text stub of one fixed shape (.text is VMA == file offset; read the bytes directly). It writes only the fixed opcode-selector bits of that (mnemonic, slot) into the slot's normalized 32-bit word(s); operand fields are deposited separately by the field/operand codec layers.

3.1 The byte sequence, decoded

  C7 07 <imm32>             [ C7 47 04 <imm32> ]            C3
  └────────┬───────┘          └───────┬───────┘             │
  movl $TEMPLATE,(%rdi)        movl $WORD1,0x4(%rdi)        ret

Decoded byte by byte — the symbol named is the real opcodedefs[i].encode_fn:

// Opcode_<mnem>_Slot_<slot>_encode(uint32_t *slotword /* rdi */)
//
//  C7 07 <imm32>      opcode C7 = MOV r/m32, imm32 ; ModR/M 07 = [rdi], imm32 = WORD0_TEMPLATE
//                     => *(uint32_t*)(rdi + 0) = WORD0_TEMPLATE;   // the (mnem,slot) selector
//
//  [ C7 47 04 <imm32> ]   ModR/M 47 04 = [rdi + 0x04], imm32 = WORD1   (WIDE/2-lane slots only)
//                     => *(uint32_t*)(rdi + 4) = WORD1;          // WORD1 == 0x00000000 invariant
//
//  C3                 RET
void Opcode_<mnem>_Slot_<slot>_encode(uint32_t *slotword) {
    slotword[0] = WORD0_TEMPLATE;            // C7 07 imm32   (always present)
    /* wide FLIX slot only: */ slotword[1] = WORD1;  // C7 47 04 imm32   (clears the 2nd lane)
    return;                                  // C3
}

• C7 07 is x86 MOV [rdi], imm32 — 07 is the ModR/M byte selecting [rdi] with an imm32 source. The four imm32 bytes (little-endian) are WORD0_TEMPLATE, the opcode-selector for this exact (mnemonic × slot). Operand fields are zero in the template.
• The optional C7 47 04 imm32 is MOV [rdi+0x04], imm32 — 47 selects [rdi + disp8], 04 is the disp8 (the second 32-bit lane). It appears only for wide-FLIX slots whose normalized opcode word spans two lanes. WORD1 == 0x00000000 is an invariant across all 12569 thunks — the upper lane carries no selector bits; the movl merely clears it (verified with zero exceptions). Narrow / scalar single-lane thunks omit this entirely.
• C3 is RET. Single-lane thunks are 7 bytes (C7 07 imm32 C3), padded to alignment with a multi-byte NOP (66 0F 1F 84 00 …); 2-lane thunks are 14 bytes.

3.2 Byte-exact samples (re-disassembled this pass)

All eight reproduce byte-exact. ivp_addnx16's F0_S3_ALU template 0x80b50000 matches its B01 roster row to the digit; wur.fsr's 0x00f3e900 = WUR_base(0x00f30000) | (UR=0xe9)<<8 matches the partition page §8.

QUIRK — the upper lane (word1) is always 0x00000000. Across all 12569 thunks, every 2-lane (wide-FLIX) thunk clears the second 32-bit lane and writes zero selector bits there. A reimplemented encoder that emits a wide slot must zero lane 1 before depositing operand bits — the template contributes nothing there. [HIGH/OBSERVED]

QUIRK — the same mnemonic has a different template in every slot it can occupy. addi's template is 0x00240000 in N0_S0_LdSt (above), 0x131c0000 in F1_S0_LdStALU, and 0x0000000b is addi.n's in Inst16a — each slot owns a different bit window of the bundle. The 12569 thunks are the full legal (mnemonic × slot) matrix. The roster row in §4.3 lists a representative slot's word0; the per-instruction reference batches expand the full set.

3.3 The symbol-mangling rule (opcodedefs[] row ↔ symtab)

Opcode_<mnem>_Slot_<slot>_encode, where both transforms are required and the mangling is injective:

1. every . in the mnemonic → _ : add.n → add_n, wur.fsr → wur_fsr, rsr.sar → rsr_sar.
2. the slot token is lowercased : Inst → inst, F2_S0_LdSt → f2_s0_ldst, N0_S0_LdSt → n0_s0_ldst.

Resolve a codec by the mangled symbol or by following opcodedefs[i].encode_fn (table field +0x10, stride 24) — both reach the same address. opcodedefs[0] (file 0x4e9640) = {opcode="excw", slot="Inst", encode_fn=0x338610}. [HIGH/OBSERVED]

3.4 The four-layer codec the thunk sits in

The encode thunk is only the opcode-selector layer. A full assemble walks four layers (full ABI on the table-schema page §5):

opcode-selector : Opcode_<mnem>_Slot_<slot>_encode   (this thunk — lays the fixed opcode bits)
operand value   : OperandSem_…_encode/_decode + _ator/_rtoa  (value ↔ field, ± PC reloc; 95 decoders)
bit-field       : Field_<f>_Slot_<s>_get/_set        (the field's bits in the 32-bit slot word; 3230 pairs)
slot scatter    : Slot_<…>_get/_set                  (the slot word ↔ the 128/64-bit bundle; 46)

The selector bits (encode) and operand bits (Field_*_set) are disjoint within the slot word — operand bits ≥ 4, selector bits 0–3 are the op0 nibble — which is why encode/decode are exact mutual inverses.

4. The master per-mnemonic encoding matrix

The full per-mnemonic encoding row is mnemonic | format | slot | unit | iclass | opcode-selector CONST | template immediate. Because one mnemonic is legal in a median of ~8.2 slots (12569 placements / 1534 mnemonics; nop alone in 44, 1178 mnemonics in ≥ 2), a literal 12569-row dump is impractical and would duplicate the per-instruction reference. This appendix instead gives:

• §4.1 — the complete per-slot placement census (the 12569 broken into the 46 slots, byte-exact, summing with zero slack), the canonical group decomposition.
• §4.2 — the complete per-package mnemonic census (the 1534 broken into 28 packages, byte-exact, summing with zero slack), the canonical roster decomposition.
• §4.3 — a representative-but-systematic sweep that exhibits one byte-grounded encoding row for every (format, slot, unit) combination — so the row schema is demonstrated across the entire grid, not just one corner.
• §6 — the batch index mapping each of the 30 per-instruction reference batches to its format/slot/iclass region, so a lookup resolves from a mnemonic to the batch that holds its full expansion.

4.1 The per-slot placement census (the 12569, grouped by slot — byte-exact)

Re-counted this pass by grouping all Opcode_*_Slot_<slot>_encode symbols (nm libisa-core.so | rg -o 'Opcode_.+_Slot_([a-z0-9_]+)_encode' | sort | uniq -c). Every slot hosts ≥ 1 opcode; the 46 per-slot counts total 12569 with zero slack.

The three None slots (N0_S1, N0_S2, N1_S1) host exactly one opcode — nop — they are NOP-only filler, not real issue units. The four Inst16a placements are exactly {add.n, addi.n, l32i.n, s32i.n}; the ten Inst16b are {beqz.n, bnez.n, break.n, halt.n, ill.n, movi.n, mov.n, nop.n, ret.n, retw.n}. [HIGH/OBSERVED]

NOTE — reading this census as the "unit" axis. The per-slot counts above are the placement grouping the appendix row's slot/unit columns index. A mnemonic's full set of placements is the set of slots in this table where it appears; the per-instruction reference batches enumerate exactly which mnemonics populate each slot. Use this census as the denominator any batch's placement tally must roll into (Σ p_i = 12569, no cross-pair with 12642).

4.2 The per-package mnemonic census (the 1534, grouped by package — byte-exact)

Parsed this pass directly from opcodes[i].package (table +0x08, stride 72, all 1534 rows; .data.rel.ro file = VMA − 0x200000). 28 distinct packages, summing to exactly 1534. This is the roster axis the appendix row's mnemonic/iclass columns draw from.

Total = 1534 (re-summed this pass). The name-prefix split is 469 / 1065 (non-ivp_ / ivp_); the package split puts 1072 in xt_ivp32. [HIGH/OBSERVED]

CORRECTION — package == xt_ivp32 (1072) is NOT the same predicate as name starts ivp_ (1065). The 7 ops in xt_ivp32 lacking the ivp_ prefix are exactly {mulsone.h, mulsone.s, recipqli.s, rur.fcr, rur.fsr, wur.fcr, wur.fsr} (re-confirmed by direct byte-parse this pass). The scalar-FP .h/.s ops are package xt_ivpn_scalarfp (102), scalar by name, counting toward the 469 scalar total. Both axes are correct; never conflate them.

4.3 The representative-but-systematic encoding sweep — one row per (format, slot, unit)

This sweep exhibits the master row schema for every distinct (format, slot, unit) combination in the 46-slot grid — so the schema is demonstrated across the entire grid, with each template immediate byte-disassembled this pass. The opcode-selector CONST and template immediate columns are the same value (the WORD0 the C7 07 imm32 lays); they are listed separately to mirror the master row schema (CONST = the selector's logical role, immediate = its literal WORD0). Escape note: a literal | inside a cell is written \|.

Every template imm above was disassembled from the named Opcode_*_encode thunk this pass. Rows marked (census: …) exist in the placement census (§4.1) but are cited there rather than re-disassembled inline. abs (a base scalar op) is not legal in the vector-only *_S3_ALU/*_S2_Mul slots (those carry only ivp_* ops), which is why the F0 ALU/Mul rows use ivp_addnx16/ivp_mulnx16 and the scalar-slot rows use abs. This demonstrates the per-opcode slot-legality the matrix encodes: a slot's roster is opcode-typed, not universal. [HIGH/OBSERVED]

NOTE — F4/F6 interiors are [MED/INFERRED]. No shipped object emits an F4/F6 bundle, so per-slot operand bit-exactness in those two formats is inferred from the identical decode path rather than oracle-confirmed on a specific bundle. The F4_S0_Ld template above is OBSERVED (the thunk bytes are real); flag any F4/F6 operand interior decode as [MED/INFERRED] unless objdump independently confirms that bundle.

5. Reconciling 12569 vs 12642 (and 1534 vs 1607)

Two distinct numbers, two distinct things — never cross-paired.

   shipped (runtime, libisa-core.so)  :  1534 mnemonics  /  12569 placements
   pre-fold (authoring, TIE-DB)       :  1607 mnemonics  /  12642 placements
   fold delta                         :   −73 mnemonics  /   −73 placements   (lockstep)

• 12569 = the Opcode_*_Slot_*_encode thunk population in libisa-core.so = num_encode_fns immediate 0x3119 = the per-slot census sum (§4.1). This is the shipped runtime placement matrix — the arbiter for anything a reimplementer builds (assembler, disassembler, ISS). [HIGH/OBSERVED]
• 12642 = the TIE-DB <OPCODEDEF> element count = 12569 + 73 — the pre-fold authoring superset in the standalone TIE database (decoded post_rewrite blob). [HIGH/CARRIED] on the total; [HIGH/OBSERVED] on the +73.

The +73 is 1607 − 1534 and 12642 − 12569 simultaneously, because each folded mnemonic carries exactly one placement in the authoring DB — they are author-time assembler/macro forms with a single canonical encoding that collapses onto an already-shipped opcode before the runtime opcodedefs[] is generated. The fold is lossless at the encoding level (every byte sequence a folded form would emit is still emitted by its base form), which is exactly why 1534/12569 is the right denominator for an encoding-completeness claim.

The fold groups (base forms ship; fold variants are confirmed absent from the roster this pass):

CORRECTION — num_encode_fns reproduces as 12569; the 12642 is NOT in this binary's tables. Re-verified this pass: num_encode_fns @ 0x3b6130 = mov $0x3119,%eax → 0x3119 = 12569, and nm | rg -c 'Opcode_.*_Slot_.*_encode' = 12569 independently. The 12642 figure is the TIE-DB authoring count, read from the decoded Xtensa.tl/Xtensa.xml, never from libisa-core.so's opcodedefs[]. Pairing 1534 ↔ 12642 or 1607 ↔ 12569 manufactures a ±73 phantom. [HIGH/OBSERVED]

CORRECTION — SortMerge is named-but-never-shipped; it is in NO denominator. A "merge two sorted subtensors" op survives only as a dead comment (// "SortMerge wip 0x97"); it has no opcodes[] row, no encode thunk, no value leaf (rg -ci sortmerge over the roster = 0). It is a fabrication wall, never a row in this appendix. [HIGH/OBSERVED]

6. The batch index — where each mnemonic's full expansion lives

The 1534 mnemonics partition into 30 per-instruction reference batches (the byte-level row expansion this appendix is the lookup for). The partition axis is the libisa mnemonic (not the ~140 firmware NEURON_ISA_TPB_OPCODE values — a different, coarser axis). Top cut: B01–B24 own the 1065 ivp_ vector ops; B25–B30 own the 469 scalar/base-Xtensa ops. Each batch pins its own OBSERVED m (mnemonic count) and p (placement count); the ≈ below are partition targets (soft at family boundaries — see the partition page), with the three hard anchors (vector 1065, scalar 469, base-Xtensa 360) [HIGH/OBSERVED].

The roll-up the 30 batches close onto: Σ m = 1534 (1065 vector + 469 scalar), Σ p = 12569 (never 12642), Σ v ≤ 864 value leaves. See the partition page §6. [HIGH/OBSERVED] on the hard anchors and the placement total; [MED/INFERRED] on the per-batch ≈.

7. Adversarial self-verification — the five strongest claims, re-derived this pass

Each re-derived independently from the binary, two ways where possible.

1. 1534 shipped mnemonics. num_opcodes @ 0x3b61d0 = mov $0x5fe → 1534; independently nm | rg -o 'Opcode_(.+)_Slot_…_encode' | sort -u | wc -l = 1534; the 28-package opcodes[].package byte-parse sums to 1534; ivp_ 1065 + non-ivp_ 469 = 1534. Four witnesses agree. [HIGH/OBSERVED]
2. 14 formats / 46 slots / 7-length classes. num_formats @ 0x3b65e0 = mov $0xe (14); num_slots @ 0x3b6510 = num_decode_fns @ 0x3b64c0 = mov $0x2e (46); the format slot-count census 1+1+1+4+5+4+4+5+4+4+4+3+2+4 = 46; the length_table[256] value census {3:128,2:96,16:22,8:8,−1:2} = 7 classes / 4 sizes. [HIGH/OBSERVED]
3. Encode-thunk ABI C7 07 imm32 [C7 47 04 imm32] C3, word1 == 0. Re-disassembled this pass: Opcode_addi_Slot_n0_s0_ldst_encode @ 0x3389b0 = c7 07 00 00 24 00 c3 (1-lane, 0x00240000); Opcode_mov_n_Slot_f0_s3_alu_encode @ 0x3386b0 = c7 07 00 d8 98 64 c7 47 04 00 00 00 00 c3 (2-lane, word0=0x6498d800, word1=0); Opcode_ivp_addnx16_Slot_f0_s3_alu_encode @ 0x343b60 = word0=0x80b50000, word1=0. The word1==0 invariant holds across all 12569 thunks. [HIGH/OBSERVED]
4. 12569 placements; reconciliation 12569 + 73 = 12642. num_encode_fns @ 0x3b6130 = mov $0x3119 (12569); nm | rg -c 'Opcode_.*_Slot_.*_encode' = 12569; the per-slot census (§4.1) sums to 12569 with zero slack. The pre-fold 12642 = 12569 + 73 and 1607 = 1534 + 73; the +73 fold forms (ffs/popc/clampsf/sextf = 0, *_w18 = 0) are confirmed absent from the roster. The only valid pairings are 1534 ↔ 12569 and 1607 ↔ 12642. [HIGH/OBSERVED] on the runtime count + fold; [HIGH/CARRIED] on the 12642 authoring total.
5. The 28-package census sums to 1534 (byte-parse, not decompile). Parsing opcodes[i].package (table +0x08, stride 72, .data.rel.ro file = VMA − 0x200000) for all 1534 rows this pass yields 28 distinct packages summing to exactly 1534, byte-identical to the coverage tally §4.1 (xt_ivp32 1072, xt_core 131, xt_ivpn_scalarfp 102, …, xt_trace 1). [HIGH/OBSERVED]

What is NOT OBSERVED at the row level. The per-batch ≈ mnemonics in §6 are partition targets, [MED/INFERRED] at family boundaries — each B-page pins its exact nm-counted m. F4/F6 per-slot operand interiors are [MED/INFERRED] (no shipped object emits those bundles). The decoded slot widths in §2.3 are [MED/INFERRED] (machine-code-emulated, ±1–2 bits on scattered slots). The v5 (Maverick) / v1 (Tonga) generations are header-OBSERVED with INFERRED interiors; the 1534/12569 cover is the gen-invariant Cairo core, so the encoding tally holds across shipped generations, but never fabricate a v5 arch_id byte or v5 image.

8. Symbol & table map

All in libisa-core.so (ncore2gp/config/) unless noted. .text/.rodata: VMA == file. .data.rel.ro/.data: file = VMA − 0x200000.

9. Cross-references

• The FLIX VLIW Encoding — the 14-format / 46-slot grid, the format_decoder/length_decoder mechanism, and the per-slot placement census (§6.3) this appendix consolidates.
• The libisa Table Schema & Codec ABI — the byte layout of opcodedefs[]/opcodes[]/slots[]/fields[] and the four-layer codec the encode thunk sits in.
• The Canonical ISA Decode Model (libisa-core) — the formats → slots → opcodes → iclasses → operands → fields object model and the decode loop.
• ISA Coverage & the 1534/1607/12642 Tally — the certified 1534/12569 denominator, the 28-package census, and the +73 fold this appendix inherits.
• The TIE Database & Four Independent ISA Sources — the authoring superset (1607/12642) and the four-source agreement.
• ISA Reference — Template & 30-Batch Partition and the thirty batch pages B01 … B30 — the byte-level row expansions this appendix is the lookup for.
• The Eight Register Files — the 8 operand-target files (AR/BR/vec/vbool/valign/wvec/b32_pr/gvr) the matrix's operand fields name.
• The Confidence & Walls Model — the tags and the named walls (F4/F6 interiors, FLIX-desync, v5, MODULE_SCHEDULE, the SortMerge phantom).

Provenance: every count, address, immediate, and template byte is [HIGH/OBSERVED] — read this pass from the count-accessor immediates (objdump -d), the nm symbol-family populations, the opcodes[]/opcodedefs[] raw byte-parse (.data.rel.ro file = VMA − 0x200000), and the literal encode-thunk bytes of the shipped libisa-core.so (sha256 8fe68bf4…f143e451). The 12642/1607 authoring totals are [HIGH/CARRIED] from the decoded TIE-DB; F4/F6 operand interiors, the decoded slot widths, and the per-batch ≈ targets are [MED/INFERRED] as flagged. All facts read as derived from shipped-artifact static analysis (lawful interoperability RE).