TAC IR

Format

TAC uses virtual registers (%r0, %r1, %r2, …) with explicit assignments:

%r0 = const_int  10
%r1 = const_int  20
%r2 = add        %r0, %r1
      arg        %r2, 0
%r3 = call       @print_i64, argc=1

Every instruction produces at most one result in a named register. Instructions without a result (like arg, store, jump) have dest = TAC_REG_NONE.

Instruction encoding

Each instruction is a fixed-size struct:

Operands are either a register reference (TAC_OP_REG), an immediate value (TAC_OP_IMM), or absent (TAC_OP_NONE).

Basic blocks

Instructions are grouped into basic blocks. Each block has a linear array of instructions and ends with a terminator (jump, branch, or ret):

fn example(x: i64) -> void:
  bb0:
    %r0 = load       local[0]
    %r1 = const_int  0
    %r2 = cmp_gt     %r0, %r1
          branch     %r2, bb1, bb2

  bb1:
    %r3 = const_str  "positive"
          arg        %r3, 0
          call       @println, argc=1
          jump       -> bb3

  bb2:
    %r4 = const_str  "non-positive"
          arg        %r4, 0
          call       @println, argc=1
          jump       -> bb3

  bb3:
          ret

Opcodes

Constants

Arithmetic

Opcodes are type-agnostic — the register’s tape_rtype_kind determines whether the backend emits integer or float instructions.

Bitwise

Comparison

Memory

Every pass treats the four atomic opcodes as it treats the volatile ones: each runs exactly once where it stands, its value used or not, and no other memory access or call moves across one. Natively each is a fixed instruction sequence (mov, xchg, lock xadd, lock cmpxchg on x86-64; ldar, stlr and ldaxr / stlxr loops on arm64), the same at -O0; the VM performs the plain operation. | move_bytes | memmove(dest, a, b): dest the destination’s address (read, not written), a the source, b the length (@move_bytes) | | fill_bytes | memset(dest, a, b): a the byte (its low 8 bits), b the length (@fill_bytes) | | heap_alloc | dest = heap_alloc(extra bytes) (zeroed allocation; with a register operand, the size comes from a) | | heap_free | heap_free(a) (give back a block heap_alloc returned) | | load_global | dest = globals[a.imm] (module-level variable) | | store_global | globals[a.imm] = b | | global_addr | dest = &globals[a.imm] (address of a module-level variable, for arrays and structs) |

Control flow

String operations

Type operations

Vectors and processor features

Functions

Each TAC function contains:

Parameters occupy registers %r0 through %r(param_count-1). Local variables are accessed by slot index via load/store.

Module

A tac_module contains:

• functions[] — all compiled functions (own module + dependencies)
• strings[] — deduplicated string literal table (and const tables)
• globals[] — module-level variables
• root_fn_offset / root_fn_count — which functions belong to the root module (vs dependencies)

Register typing

Every virtual register and local slot has an associated tape_rtype_kind:

Wide values

Types larger than 64 bits (structs, strings, slices) are stack-allocated via alloca. The register holds a pointer to the stack slot:

%r0 = alloca      24          // allocate 24 bytes for Vec3
      store_field %r0, %r1    // off=0: x
      store_field %r0, %r2    // off=8: y
      store_field %r0, %r3    // off=16: z

Why not stack-based bytecode?

Tape 1.0 used stack-machine bytecode. Problems:

• Reverse-engineering value flow for native codegen
• Phantom operand bugs
• Undebuggable calling conventions

TAC eliminates all of these by making data flow explicit. Both the VM interpreter and native backends read the same representation without needing a decompilation step.

Last modified: 2026-10-26 08:47:29 UTC