ManiT Compiler: Why Ternary Needs
Its Own Instruction Set

The ISA Is the Contract

An instruction set architecture (ISA) is the most fundamental interface in computing. It defines the contract between software and hardware: the format of instructions, the set of registers, the addressing modes, the available operations, and the rules for how they interact. Every program — from a kernel boot loader to a web browser — is ultimately a sequence of ISA instructions.

When the hardware changes fundamentally — when the basic unit of information shifts from a bit to a trit — the ISA must change with it. You cannot run x86 or ARM instructions on ternary hardware any more than you can run vinyl records on a CD player. The encoding, the semantics, the very meaning of the bits (now trits) is different.

This is why Patent P4 exists: to define T3ISA (Ternary Three-Trit Instruction Set Architecture) and the ManiT compiler that generates T3ISA machine code.

Designing the Instruction Word

The first design decision for any ISA is the instruction word width. In binary architectures, common widths are 16 bits (Thumb), 32 bits (ARM, RISC-V), and variable (x86). The choice balances code density against instruction expressiveness.

For a ternary architecture, powers of 3 are the natural widths. T3ISA uses a 27-trit instruction word — 3³ = 27. This is not just numerologically satisfying; it has practical consequences:

27-trit instruction word

  3²⁷ = 7,625,597,484,987 possible instruction encodings
  (compared to 2³² = 4,294,967,296 for a 32-bit binary ISA)

  A 27-trit word carries 27 × log₂(3) ≈ 42.8 bits of information
  → More expressive than a 32-bit binary instruction
  → Comparable to a 43-bit binary instruction

The 27-trit word is divided into fields: opcode, register specifiers, immediate values, and addressing mode bits — all expressed in balanced ternary. The specific field layout is defined in Patent P4 and is not detailed here, but the key principle is that every field is trit-aligned, meaning fields occupy whole-trit boundaries.

Ternary Registers

T3ISA defines registers that are 27 trits wide, matching the instruction word width. Each register can hold a balanced ternary integer in the range ±(3²⁷ − 1)/2 — approximately ±3.8 trillion. This is a larger range than a 32-bit binary register (±2.1 billion) with the same "width" in digits.

The register set includes nine general-purpose registers (r0 through r8 — nine being 3²), a stack pointer, a program counter, and a 4-trit status register. The choice of nine general-purpose registers is deliberate: register specifiers in ternary need log₃(9) = 2 trits per register field, keeping the instruction encoding compact.

Instruction Categories

T3ISA instructions fall into the standard categories familiar from any ISA design textbook, but with ternary-specific operations:

Three-Way Branching

Binary architectures typically offer two-way branches: taken or not taken. This maps to a single bit (the condition flag). Ternary comparison produces a trit: −1 (less than), 0 (equal), or +1 (greater than).

T3ISA exploits this with branch instructions that test the sign of a comparison result directly:

; Three-way branch example
    TCMP    r0, r1          ; compare r0 with r1
                            ; result trit: −1 if r0 < r1
                            ;               0 if r0 = r1
                            ;              +1 if r0 > r1

    TBRN    .less_than      ; branch if negative (−1)
    TBRZ    .equal          ; branch if zero (0)
    TBRP    .greater_than   ; branch if positive (+1)

; In binary, this requires two compare-and-branch sequences.
; In ternary, one comparison produces a three-way result.

This is not just elegant — it is faster. A common pattern like a three-way switch (less/equal/greater) takes one comparison and one branch in ternary, versus two comparisons and two branches in binary. For code that does heavy sorting or searching, this translates to measurable performance improvement.

TMAJ as a Hardware Instruction

In binary ISAs, there is no NAND instruction — NAND is a gate-level operation, not an instruction. This is because binary ISAs already include AND, OR, XOR, and NOT, which are sufficient.

In T3ISA, the ternary majority operation (TMAJ) is an instruction. TMAJ3 computes median(A, B, C) for three register values. This mirrors the hardware gate (Patent P6's TMAJ3 cell) and is used directly in the ALU for carry computation in ternary addition, majority voting, and median filtering.

The Compiler Pipeline

The ManiT compiler follows the standard compiler architecture that has been well-understood since Aho, Sethi, and Ullman's "Dragon Book" (1986):

1. Lexer: Tokenises .t3s source files into T3ISA mnemonics, register names, labels, and ternary literals
2. Parser: Validates instruction syntax, resolves label references, checks register specifier ranges
3. Code generator: Encodes each instruction into a 27-trit binary representation, producing .t3b object files
4. Linker: Resolves cross-module references, assigns trit-aligned addresses, produces a final executable .t3b binary

The compiler pipeline itself is implemented in standard tools (not in ternary) — it runs on a binary host machine and cross-compiles to ternary. This is the same approach used in every embedded systems toolchain: the compiler runs on a development workstation and produces code for the target architecture.

Ternary-Specific Challenges

Several aspects of code generation are fundamentally different for ternary:

• Immediate encoding: Ternary immediate values in instructions must be encoded in balanced ternary within the instruction word. There is no sign bit — the balanced representation is inherently signed.
• Address arithmetic: Branch target calculation uses ternary arithmetic, not binary. PC-relative offsets are balanced ternary values, which means forward and backward branches are symmetric (no unsigned offset bias).
• No two's complement: Arithmetic overflow behaves differently. In balanced ternary, the overflow of an addition produces a carry trit (−1, 0, or +1), not a carry bit. The ManiT compiler must generate code that handles ternary carry propagation correctly.
• Trit-aligned data: All data structures must be aligned to trit boundaries, not byte boundaries. The concept of a "byte" does not exist in T3ISA; the fundamental addressable unit is a trit.

The Proof: Compiling a Kernel

The strongest validation of any compiler is compiling a real program and having it work. The ManiT compiler was used to compile the entire THATTE-OS kernel — eight source modules totalling several hundred lines of T3ISA assembly — into a linked binary.

ManiT v0.1.0 — THATTE-OS Kernel Build

  Source modules: boot.t3s, init.t3s, sched.t3s, irq.t3s,
                  proc.t3s, syscall.t3s, mem.t3s, io.t3s

  Compiled objects: 8 × .t3b files
  Linked binary:    thatte_os.t3b (72 KB)

  Verification:
    ✓ All three trit states present in output binary
    ✓ Instruction encodings match T3ISA specification
    ✓ Label references resolved correctly across modules
    ✓ Boot entry point at trit address 0
    ✓ Execution traces verify correct instruction dispatch

The 72 KB binary and all intermediate .t3b files are included as Appendix B to Patent P5 (THATTE-OS). This means the patent filing contains machine-verifiable proof that the compiler works and produces correct code — not just a theoretical description.

Why a Compiler Patent?

A compiler that generates balanced ternary machine code is novel not because compilation is new (it is not), but because the target architecture is new. The specific instruction encoding, the ternary field layout, the handling of ternary arithmetic semantics, and the trit-aligned code generation are all novel aspects that did not exist before T3ISA.

Patent P4 (IPC G06F 8/40 — compilation and code generation) covers the method of generating balanced ternary machine instructions for execution on THATTE Structure FET hardware. It is the software bridge between the ternary logic layer (P6) and the system software layer (P5, P8).