Project Logs

Collapse

• Build Log #1 — The Five Impossibilities, or: How a Failed Audit Founded a CPU

  Tsuneo.Ohnaka • 07/13/2026 at 13:55 • 0 comments

  (draft for hackaday.io/project/206144 · derived from PROJECT_ABSTRACT_canonical.md · 2026-07-13)

  The most productive design review in this project's short history is one we got wrong.

  PTSG-CPU-Formation is the third repository of the PTSG ecosystem, and its first Formation: a minimal instruction-driven datapath — accumulator, Horner-step MAC, an explicit data stack, packet-parameter memory with atomic boundary commit — built around the frozen PTSG-Core, entirely inside the Core's window discipline. One line: a deterministic data machine built on a clock that cannot be argued with.

  It was born sideways, the way everything in this ecosystem is born. While drafting the packet-parameter engine for the FPGA Spectrum Engine's WPMS synthesizer, the instruction set kept growing more general than its application. So we ran a review with an inverted question. Not what should we add? but: what can this machine never be — not inefficiency, impossibility?

  The audit came back with five impossibilities, each one the shadow of a doctrine we actually wanted:

  1. It cannot branch on its own data. No flags register, no compare. The core is data-blind by creed.
  2. It cannot capture a return address. No subroutines, no recursion — because the timing chart must stay readable as the program text.
  3. It cannot read its own writes within a window. Staging lands on a shadow page; the page you're playing from cannot be touched.
  4. It cannot own its program. No load path, no self-modification. The tines of the music box are planted from outside; the planting is the performance.
  5. It cannot be interrupted. Preemption is jitter incarnate.

  Tidy. Convincing. And then we read the Core repository properly — and two of the five collapsed. The Core already captures return contexts (a holding register auto-saves state on branch, call, and insertion; an external stack bus delegates nesting depth outward), and it already has interrupts: Insertion exists, honored at packet boundaries — not absent, but quantized to the deterministic grid. A third impossibility turned out to have a front door (ALU flags exported as external Condition lanes, so the core stays data-blind while the loop closes outside), and a fourth turned out to be doctrine — a per-profile choice, not law.

  Only one impossibility was actually law: the program's owner stands outside the machine.

  That correction was the founding insight. A machine this close to CPU-hood, held back only by chooseable doctrine, deserved its own repository — a master data ISA from which applications are made by subtraction. The WPMS engine becomes the first subtraction profile, and the parent project stays what it has always been: the mother that keeps birthing generic children and becomes each child's first customer.

  What exists as of tonight, in the same launch shape PTSG-Core itself once had:

  • The repository, four Open Prompt layers, CC0/CC0/MIT/CC0.
  • Five Layer-1 chapters: philosophy (including the corrected audit — the impossibilities we keep are the product), the register file and the read-only quartet SN/SSS/K/I (now, here, when, which — time itself as an operand), the Command × Phase behavior table (eighteen instructions; no instruction exists until its row is ratified), the memory architecture (BG computes, Q commits: the page swap lands jitter-free on the packet boundary, so glitch-freedom is structure, not discipline), and the Core interface contract (nine lanes; "the Core never waits").
  • The deliberation worksheet and the founding dialogue itself, published as the first Layer-2 reasoning trace — this ecosystem publishes its design conversations, architect and AI amanuensis both, as reproducible public record.

  You will find no resource figures in this log, and none anywhere in the repository outside Layer 4. That is a governance rule, not an oversight: Measured, not promised. Numbers will exist only as measurements pinned to a named revision, device, and toolchain — the first of which will arrive with silicon evidence...

  Read more »

View project log