SMIR · SMIRE · work in progress

An intermediate
representation for
control code.

Industrial logic is written in a dozen dialects and reasoned about in none of them. We are building SMIR: one explicit, language-agnostic representation of what a program actually does — control flow, state, I/O and types — and SMIRE, the engine that parses code into it, checks it, and generates code back out.

// a function, as SMIR sees it
{
  "smir_version": "0.1.0",
  "functions": [{
    "name": "add_one",
    "params": [{ "name": "n", "type": "int" }],
    "cfg": {
      "entry": "block_0",
      "blocks": [{
        "id": "block_0",
        "statements": [{ "kind": "assign", … }],
        "terminator": { "kind": "return", … }
      }]
    },
    "io": { "rows": [], "conflicts": [] }
  }]
}

source→parse→SMIR→validate→run→generate

Explicit control flow

Every function becomes a control-flow graph of basic blocks with a single terminator: jump, branch, loop or return. No hidden edges, nothing implied by indentation.

State as a first-class citizen

Step machines, transitions and their guards are part of the representation rather than a pattern you have to recognise in a CASE block.

I/O it can account for

A cross-reference of every signal read and written, per block — which is what makes conflicting writes and dead outputs findable instead of debatable.

Round-trip, checked

SMIRE parses code into SMIR and generates it back; the result is compiled and executed in a sandbox. If the behaviour differs, the representation is wrong — not the code.

Where we are