T81 Foundation


title: T81 Foundation Specification — TISC nav:


← Back to Spec Index

TISC — Ternary Instruction Set Computer

Version 1.1 — Stable

Status: Stable
Last Revised: 2026-03-01
Applies to: T81VM, T81Lang, Axion, Cognitive Tiers

Freeze Exception — 2026-03-01
Scope: Additive corrections only — no existing opcode semantics changed.
Authorized by: @t81dev
Rationale: §5.14 adds seven bitwise opcodes (BITAND, BITOR, BITXOR, BITNOT, BITSHL, BITSHR, BITUSHR) that are implemented in the VM and emitted by the T81Lang compiler’s lowering pass but were absent from the normative spec, causing external readers to miss valid instruction-set surface.

This document defines the Ternary Instruction Set Computer (TISC) for the T81 Ecosystem.
It is normative for all instruction encoding, execution semantics, and VM integration.


0. Binary Host Execution Boundary

T81 is a ternary semantic architecture executed on binary hardware. This is an intentional architectural layer. TISC operates semantically as a ternary computer, yet the implementation relies on 2-bit packed trits and SWAR vectorization to interface with the binary substrate of host systems. This approach achieves maximum performance on x86 and ARM while preserving bit-exact, deterministic ternary state.

0.5. Design Principles

TISC MUST satisfy:

  1. Deterministic Execution
    Each instruction has a single, total, unambiguous semantic definition.

  2. Base-81 / Balanced Ternary Semantics
    Arithmetic and logic are ternary-native; binary implementation shortcuts MUST NOT change observable behavior.

  3. Zero Undefined Behavior
    Every operand combination either:

    • produces a canonical result, or
    • yields a deterministic fault.
  4. Axion Visibility
    All state changes, faults, and privileged operations MUST be observable by the Axion kernel.

  5. Layer Compatibility
    TISC must:


1. Machine Model

The abstract TISC machine state is:

STATE = (R, PC, SP, FLAGS, MEM, META)

The T81VM is responsible for hosting and evolving this state; TISC defines how each instruction transforms it.

A simple TISC program to add two numbers might look like this:

; Load the integer value 5 into register R0
LOADI R0, 5

; Load the integer value 10 into register R1
LOADI R1, 10

; Add the values in R0 and R1, store the result in R2
ADD R2, R0, R1

; Halt the machine
HALT

Complex Arithmetic & Comparison Example

; Floating point arithmetic
LOADI R0, 1.5           ; Load float handle
LOADI R1, 2.5           ; Load another float handle
FADD R2, R0, R1         ; R2 = 4.0 handle

; Comparison and conditional jump
LOADI R3, 10
CMP R2, R3              ; Compare 4.0 with 10
JN label_less           ; Jump if negative (4.0 < 10)
HALT

label_less:
LOADI R4, 1
HALT

Tensor Operation Example

; Assuming handles are pre-loaded or created via language frontend
LOADI R1, 1             ; Tensor handle 1
LOADI R2, 2             ; Tensor handle 2
TVECADD R0, R1, R2      ; Elementwise vector add
HALT

Stack Management & Function Call Example

; main entry
LOADI R0, 42            ; Argument for function
PUSH R0                 ; Push argument to stack
LOADI R1, label_func    ; Function address
CALL R1                 ; Call function
POP R2                  ; Pop result from stack (assuming ABI uses stack for return)
HALT

label_func:
POP R3                  ; Pop argument from stack
LOADI R4, 1
ADD R5, R3, R4          ; result = arg + 1
PUSH R5                 ; Push result to stack
RET                     ; Return to caller

Axion Policy & Metadata Example

; Read current instruction count from Axion
; IMM_TAG 0: Instruction Count (hypothetical tag)
AXREAD R0, 0

; Set a new stack limit for current context
; IMM_TAG 1: Max Stack Depth (hypothetical tag)
LOADI R1, 1024
AXSET 1, R1

; Verify current state against ethical constraints
AXVERIFY R2
JZ R2, label_unsafe     ; If result is zero (fail), jump to handler
HALT

label_unsafe:
TRAP 1                  ; Trigger security trap
HALT

2. Register File

TISC defines a mandatory architectural register window of 81 registers, indexed R0 through R80.

2.1 General-Purpose Registers

2.2 Axion System Window (R75–R80)

Registers R75 through R80 form the fixed Axion System Window. These registers are managed by the VM and Axion kernel to provide high-visibility architectural state.

Register Purpose
R75 Global Tick
R76 Lineage Root Hash
R77 Current Entropy Signature
R78 Active Constitutional Mask
R79 Recursion Depth Counter
R80 Axion Seal / Capability Word

Any attempt by unprivileged instructions to directly modify registers in the R75–R80 range MUST be ignored or trigger a deterministic Security Fault, depending on the active Axion policy.

2.3 Implementation-Defined Extended Register Banks

Implementations MAY expose additional internal registers beyond R80 (for example, implementation-local scratch/context banks), but they are non-portable and outside the mandatory architectural contract.

Requirements:

  1. The semantics of R0–R80 MUST remain unchanged and portable.
  2. Programs that target the canonical deterministic profile MUST NOT rely on registers outside R0–R80.
  3. If an implementation exposes extended registers, this MUST be documented as an implementation profile and MUST NOT silently alter the meaning of canonical opcodes over R0–R80.

3. Memory Model

Memory is a flat, addressable ternary space partitioned into segments:

The exact physical representation is implementation-defined, but:

  1. Addressing MUST be deterministic and reproducible.
  2. Alignment MUST follow base-81 multiples for composite structures.
  3. Out-of-bounds access MUST cause a deterministic fault (no undefined reads/writes).

4. Instruction Encoding

For the current canonical runtime/toolchain profile (v1.1), each TISC instruction is encoded as a fixed-width 13-byte record:

[ OPCODE:u8 | A:i32 | B:i32 | C:i32 ]   // little-endian i32 operands

The byte-level encoding above is the normative interchange representation used by encode/decode in the current implementation profile.

Conceptual ternary field decompositions MAY still be used for architectural reasoning, but they MUST map deterministically to the canonical 13-byte form.

Decoding requirements:

4.1 Native Ternary Transition Profile (Planned)

T81’s long-term direction includes native ternary instruction-word execution. To preserve compatibility and auditability during that transition:

  1. Any native ternary instruction layout MUST define a deterministic, lossless mapping to/from the canonical 13-byte interchange form.
  2. Profile identifiers MUST make encoding mode explicit at artifact boundaries (compiler output, loaders, and replay tools).
  3. ISA semantics for R0–R80 and opcode behavior MUST remain unchanged across encoding profiles.

5. Opcode Classes

This section defines the normative opcode classes and their semantics. Implementations MAY add extensions via future RFCs but MUST NOT alter existing behavior.

For each instruction:

5.1 Notation


5.2 Arithmetic Instructions

All arithmetic uses T81BigInt semantics unless otherwise noted. Registers that refer to T81Float or T81Fraction values SHALL contain canonical pool handles (1-based indices into the literal/value pools defined by the program image). Any opcode that dereferences a handle MUST fault with IllegalInstruction if the handle is zero, negative, or out of range.

ADD

SUB

MUL

DIV

MOD

NEG

INC / DEC

FADD / FSUB / FMUL / FDIV

FRACADD / FRACSUB / FRACMUL / FRACDIV

CHKSHAPE

MAKE_OPTION_SOME

MAKE_OPTION_NONE

MAKE_RESULT_OK

MAKE_RESULT_ERR

OPTION_IS_SOME

OPTION_UNWRAP

RESULT_IS_OK

RESULT_UNWRAP_OK

RESULT_UNWRAP_ERR

Conformance programs: spec/conformance/tisc/arithmetic-determinism.t81 · division-truncation.t81 · fraction-normalization.t81


5.3 Ternary Logic Instructions

Logical operations operate over Trits or T81BigInt viewed as vectors of trits.

TNOT

TAND / TOR / TXOR

Conformance program: spec/conformance/tisc/ternary-logic-canonical.t81


5.4 Comparison and Flags

CMP

SETF

Conformance program: spec/conformance/tisc/comparison-total-order.t81


5.5 Move and Data Movement

MOV

LOADI


5.6 Memory Access

LOAD

STORE

PUSH / POP

Conformance program: spec/conformance/tisc/bounds-fault-contract.t81


5.7 Control Flow

All jumps are deterministic and MUST NOT permit self-modifying code.

JMP

JZ / JNZ / JN / JP

CALL / RET


5.8 Tensor and Matrix Operations

Act on canonical tensor/matrix representations as defined in Data Types.

TVECADD

TMATMUL

TTENDOT


5.9 Conversion Instructions

Conversions MUST be explicit and deterministic.

I2F / F2I

I2FRAC / FRAC2I

Conformance program: spec/conformance/tisc/conversion-determinism.t81


5.10 Axion-Privileged Instructions

These instructions are only valid in Axion-supervised or privileged contexts.

AXREAD

AXSET

AXVERIFY

Any attempt to execute Axion instructions from non-privileged context MUST be treated as a Security Fault.

Tier restriction (cross-reference): AXREAD and AXSET are restricted to Tier 2 and above per cognitive-tiers.md §1. AXVERIFY is the only Axion privileged instruction permitted in Tier 1.

Conformance program: spec/conformance/tisc/tier-restriction.t81


5.11 Trigonometric Instructions

Trigonometric operations on canonical T81Float values.

FSIN / FCOS / FTAN


5.12 System and Miscellaneous

NOP

HALT

TRAP


5.13 Governed Memory Access

Instructions that interact with content-addressed storage (CanonFS) under Axion governance.

TLOADHASH


5.14 Bitwise Integer Operations

These instructions perform standard binary bitwise operations on T81BigInt operands. Operands are interpreted as two’s-complement binary integers for the purpose of bit-level manipulation; the result is stored as a canonical T81BigInt.

Freeze Exception addition — 2026-03-01. These opcodes are emitted by the T81Lang compiler lowering table (§5 of t81lang-spec.md) and implemented in core/vm/vm.cpp. They were omitted from previous spec versions.

BITAND

BITOR

BITXOR

BITNOT

BITSHL

BITSHR

BITUSHR

Conformance programs: spec/conformance/tisc/bitwise-determinism.t81 · bitwise-shift-masking.t81


5.15 AI-Native Inference Operations (RFC-0026)

These instructions are Tier 2+ only. All operate on TensorHandle registers. All are subject to Axion pre-instruction verification before execution begins. Hardware floating-point is prohibited; all arithmetic uses the canonical T81Float soft-float path defined in spec/t81-data-types.md §4.

Freeze Exception addition — 2026-03-07 (RFC-0026 AI-M1–M5). These opcodes are emitted by AI inference workload compilation paths and implemented in core/vm/vm.cpp. Opcode byte assignments: ATTN=0xBB, QMATMUL=0xBC, EMBED=0xBD, WLOAD=0xBE, GATHER=0xBF, SCATTER=0xC0.

Packed Operand Encoding

When two register indices must be passed in a single 32-bit operand field, the PACK(X, Y) encoding is used:

packed = (X & 0xFF) | ((Y & 0xFF) << 8)

Both X and Y are decoded as unsigned 8-bit values. This encoding is used by ATTN, QMATMUL, GATHER, and SCATTER.

ATTN — Scaled Dot-Product Attention

QMATMUL — Quantized Matrix Multiply

EMBED — Embedding Lookup

WLOAD — Weight Load with Policy Gate

GATHER — Sparse Gather

SCATTER — Sparse Scatter-Add

Tests: tests/cpp/vm_ai_phase1_wload_canonfs_audit_test.cpp · tests/cpp/vm_ai_phase1_gather_axis1_test.cpp · tests/cpp/vm_ai_phase1_scatter_aliasing_test.cpp


6. Fault Semantics

All faults are deterministic and Axion-visible. TISC MUST NOT allow silent corruption or undefined behavior.

6.1 Fault Categories

6.2 Fault Handling

On any fault:

  1. T81VM MUST stop normal instruction execution.

  2. Fault record MUST be stored in Axion-visible metadata.

  3. Axion MAY decide to:

    • terminate
    • roll back
    • escalate to cognitive tiers (in supervised analytic modes)

No fault may leave the machine in an unspecified or partially-updated state; either:


Cross-References

Overview

Data Types

T81 Virtual Machine

T81Lang

Current spec version: v1.2 (updated 2026-03-01).

Axion

Cognitive Tiers