Three != Two: A Complete Balanced Ternary Software Stack is the evaluation the release was missing. Not a manifesto — a measurement. Every claim in it is checkable against the public repositories, and the paper is deposited with the software rather than instead of it:
doi.org/10.5281/zenodo.21894460 — 13 pages, CC BY 4.0.
What the Paper Claims — and What It Doesn't
The stack has no ternary hardware to be measured on, so the meaningful correctness question is self-consistency: every shipped program is compiled through one front end to two independent backends — LLVM IR for the machine on your desk, and T3ISA, the 27-trit instruction set — and the outputs are compared byte for byte. 18 of 20 programs are byte-identical, and the two that diverge are characterised exactly, reproduction included.
On the ternary target the same source compiles to 1.6–2.2× fewer assembly lines, and 7–9% of executed instructions are operations with no single-instruction binary equivalent. In thatteOS, privilege is one trit and permission checking is the ternary minimum function — escalation is excluded by an algebraic identity rather than by a code path.
And what it does not claim, stated in the paper more than once: nothing about speed, and nothing about efficiency. No ternary hardware was used; the emulator's timings measure interpretation overhead. The honest headline is the same program, expressed in fewer instructions with less enforcement machinery, on an architecture whose performance is unmeasured because it does not yet physically exist.
The Defects Are the Finding
Section 7.3 is the part I most want read. It reports two defects the cross-backend comparison caught that the 313-test suite had been green over. In one of them, ternary arithmetic was silently saturating at the 27-trit maximum — and the test suite stayed green because the golden file recorded the wrong answer as the expected output. A test suite cannot find a defect that its own expected outputs encode. Only a second, independent implementation could — and that is the methodological result: a dual-target compiler is a differential testing apparatus, and for a stack whose reference semantics cannot yet be checked against real hardware, it is the only oracle available.
Built to Outlive Its Links
Everything now has a permanent identifier, independent of any one website — including this one:
- The paper — 10.5281/zenodo.21894460 (Zenodo, CC BY 4.0).
- maniTC — release v0.1.0 archived with DOI 10.5281/zenodo.21894912, and the full repository, commit history included, preserved by Software Heritage.
- thatteOS — release v0.1.0 archived with DOI 10.5281/zenodo.21894914, likewise preserved by Software Heritage.
The paper and the code records cite each other on Zenodo, so a reader who arrives at any one of them can reach all of them — even if GitHub, or this site, were gone tomorrow. That is what publication should mean.
Read It, Break It, Cite It
The paper states its limitations in full — section 8, including the one
cross-backend divergence not yet fixed — and the repositories carry
KNOWN_ISSUES.md as the living version of that list. If you work
in multiple-valued logic, compilers, or OS internals, I would rather have
the limitations read carefully than the headline numbers repeated. And if
you find something wrong, the first person who did got their bug fixed
inside two days — the paper's acknowledgements tell that story.
The hardware those instructions were designed for advances on its own track — the twelve patent specifications are filed, and the device architecture is deliberately not described in this paper. The software is not waiting, and neither should you.