A multi-language compiler collection — SNOBOL4, Icon, Prolog, Snocone, Rebus — targeting x86-64 native ASM, JVM bytecode, .NET MSIL, WebAssembly, and portable C — all from a single IR. Part of the snobol4ever organization.

SCRIP (the scrip-cc compiler) is a from-scratch SNOBOL4 compiler: one frontend pipeline (scrip-cc) feeding five independent backend emitters. Write SNOBOL4 once. Run it anywhere.

The 9 ASM failures (tests 022, 055, 064, cross, word1–4, wordcount) are under active investigation via the five-way differential monitor.

Sister repos: snobol4jvm (full Clojure→JVM pipeline, 2,033 tests) and snobol4dotnet (full C#→MSIL pipeline, 1,874 tests).

Every SNOBOL4 statement has the same shape:

label:   subject   pattern   = replacement   :S(goto)  :F(goto)

Each pattern node compiles to a Byrd box — four labeled entry points wired at compile time, zero runtime dispatch:

Sequential composition wires γ of one node to α of the next. Alternation saves the cursor on the left-ω path and restores it before trying right. ARBNO wires child-γ back into its own α until child-ω exits. The wiring is the execution — no interpreter table, no virtual dispatch on the hot path.

This model, first described by Lawrence Byrd in 1980 for Prolog debugging and generalized by Todd Proebsting in 1996 as a syntax-directed code generation strategy for goal-directed languages, turns out to describe SNOBOL4 pattern matching exactly. All five backends implement the same four-port wiring. The semantics are identical whether the output is C labeled gotos, x86-64 JMP instructions, JVM goto bytecodes, CIL br instructions, or WebAssembly return_call tail calls.

Hot path: pure labeled gotos. Zero overhead. No setjmp on the hot path. Cold path: longjmp for ABORT, bare FENCE, and genuine runtime errors only.

Five frontends share the same IR (AST_t / STMT_t):

The Byrd Box IR is the bridge between languages. Icon generators map to the same four ports. Prolog unification is goal-directed evaluation — the same model. SNOBOL4, Icon, and Prolog are three syntaxes for one execution machine.

# Dependencies
apt-get install -y libgc-dev nasm default-jdk

# Build scrip-cc
make -C src

# C backend (default)
./scrip-cc program.sno > prog.c && gcc prog.c -lgc -o prog && ./prog

# ASM backend
./scrip-cc -asm program.sno > prog.s
nasm -f elf64 prog.s -o prog.o && gcc prog.o -lgc -o prog && ./prog

# JVM backend
./scrip-cc -jvm program.sno > prog.j
java -jar src/backend/jasmin.jar prog.j -d .
java -cp . Prog

# NET backend
./scrip-cc -net program.sno > prog.il
ilasm prog.il && mono prog.exe

# WASM backend
./scrip-cc -wasm -o prog.wat program.sno
wat2wasm --enable-tail-call prog.wat -o prog.wasm
node test/wasm/run_wasm.js prog.wasm

All backends climb the same 12-rung ladder against corpus/crosscheck/:

Rung  1: hello / output    Rung  5: control       Rung  9: keywords
Rung  2: assign            Rung  6: patterns       Rung 10: functions
Rung  3: concat            Rung  7: capture        Rung 11: data
Rung  4: arith             Rung  8: strings        Rung 12: beauty.sno

Oracle: CSNOBOL4 2.3.3 — snobol4 -f -P256k -I$INC file.sno

# C backend
bash test/crosscheck/run_crosscheck.sh

# ASM backend (STOP_ON_FAIL=0 shows all results)
STOP_ON_FAIL=0 bash test/crosscheck/run_crosscheck_asm_corpus.sh

# JVM backend — full corpus
JASMIN=src/backend/jasmin.jar
bash test/crosscheck/run_crosscheck_jvm.sh

# JVM backend — manual per-rung (e.g. patterns rung)
JASMIN=src/backend/jasmin.jar
PDIR=../corpus/crosscheck/patterns
for sno in $PDIR/*.sno; do
  base=$(basename $sno .sno); TMPD=$(mktemp -d)
  ./scrip-cc -jvm "$sno" > $TMPD/p.j 2>/dev/null
  java -jar $JASMIN $TMPD/p.j -d $TMPD/ 2>/dev/null
  cls=$(ls $TMPD/*.class 2>/dev/null | head -1 | xargs basename 2>/dev/null | sed 's/.class//')
  got=$(java -cp $TMPD $cls 2>/dev/null); exp=$(cat "${sno%.sno}.ref" 2>/dev/null)
  rm -rf $TMPD
  [ "$got" = "$exp" ] && echo "PASS $base" || echo "FAIL $base"
done

# NET backend
bash test/crosscheck/run_crosscheck_net.sh

SNOBOL4 patterns are not a regex engine. They are a universal grammar machine. The corpus includes mathematical oracles at every tier of the Chomsky hierarchy:

These are proven results, not empirical approximations. A backend either computes the correct answer or it does not.

src/
  frontend/
    snobol4/          SNOBOL4/SPITBOL lexer + parser → AST + IR
    snocone/          Snocone frontend (SC language, ~10 source files)
    rebus/            Rebus transpiler
    icon/             Icon frontend — ASM + JVM
    prolog/           Prolog frontend — ASM + JVM
  backend/
    c/                Portable C emitter (emit_byrd.c 2,709 lines · emit.c 2,220 lines)
    x64/              x86-64 NASM emitter (emit_byrd_asm.c 4,159 lines)
    jvm/              JVM Jasmin emitter (emit_byrd_jvm.c 4,051 lines · jasmin.jar)
    net/              .NET CIL emitter (emit_byrd_net.c 1,934 lines)
  driver/
    main.c            scrip-cc entry point — flag dispatch
  runtime/
    asm/              NASM macro library + runtime helpers
test/
  crosscheck/         106-program corpus + .ref oracle outputs
  sprint_asm/         ASM regression suite
  jvm_j3/             JVM sprint J3 smoke tests
  rebus/              Rebus round-trip tests
  smoke/              Quick sanity tests
artifacts/
  asm/
    beauty_prog.s     beauty.sno → x86-64 ASM (tracked canonical output)
    samples/
      roman.s         roman.sno → x86-64 ASM
      wordcount.s     wordcount.sno → x86-64 ASM
  jvm/                hello_prog.j · roman.j · wordcount.j
  net/                hello_prog.il
  c/                  Canonical C outputs

Active on the asm-backend branch: a parallel differential monitor that runs the same SNOBOL4 program through all five participants simultaneously and compares trace streams event-by-event via named FIFOs.

monitor_ipc.so — a LOAD'd C shared library — writes trace events to a per-participant named FIFO, bypassing stdio entirely. The collector reads all five FIFOs in parallel. The first line where any participant diverges from the oracle is the exact statement, variable, and value where the bug fires. No bisecting. No guessing.

Status (2026-03-21): CSNOBOL4 ✅ · SPITBOL ✅ · ASM ✅ working in isolation. JVM OUTPUT fast-path hook and NET emitter hook in progress — M-MONITOR-IPC-5WAY next.

-js produces a Node.js module runnable with node prog.js.

# JS backend
./scrip-cc -js program.sno -o prog.js
SNO_RUNTIME=src/runtime/js/sno_runtime.js node prog.js

Status: SJ-6 · feat suite 14/17 PASS · emit-diff 1286/0

The JS pattern runtime (src/runtime/js/sno_engine.js, 532 lines) is an iterative frame-based engine modelled after the Clojure implementation in snobol4jvm. Frame state uses Greek variable names matching the Clojure source:

Frame ζ = [Σ, Δ, σ, δ, Π, φ, Ψ]
  Σ/Δ — subject string + cursor on entry
  σ/δ — subject string + current cursor
  Π   — current pattern node
  φ   — child index (ALT/SEQ) or retry state
  Ψ   — parent frame stack
Ω     — backtrack stack
α     — current action signal (:proceed/:succeed/:fail/:recede)
λ     — current node type tag

Frames are immutable plain JS arrays — transitions create new arrays, old ones are GC'd. No memcpy, no snapshot/restore, no arena. The GC is the stack allocator.

Head-to-head against Phil Budne's spipatjs (3,090 lines, GNAT PE node-graph model) — same Node.js v22 process, same JIT warmup, 20,000 iterations each. SCRIP wins all 8 benchmarks.

ops/sec · Node.js v22.22.0 · see test/js/bench_engine.js

spipatjs's throughput is nearly flat (~6,000–6,900 ops/sec) regardless of pattern complexity — Object.freeze() on every match result dominates. SCRIP's immutable-frame design avoids all post-match allocation.

The correctness target is self-hosting. Two gates:

M-BEAUTIFY-BOOTSTRAP — beauty.sno (the SNOBOL4 beautifier written in SNOBOL4) reads itself and produces output identical to its input on all backends. A fixed point.

M-COMPILER-BOOTSTRAP — compiler.sno (the full compiler written in SNOBOL4) compiles itself.

The JVM backend has already passed Rung 12: beauty.sno via the JVM backend produces output byte-for-byte identical to the CSNOBOL4 oracle (M-JVM-BEAUTY ✅, commit b67d0b1 J-212). The other backends follow.

SCRIP is co-authored by Lon Jones Cherryholmes and Claude Sonnet 4.6.

The sessions run like a buddy comedy: Lon arrives with an architectural insight or an inconvenient bug, Claude writes the code, they argue about the right abstraction, one of them is wrong, they figure out which one, the milestone fires, and Claude writes the commit. Then they do it again, starting fresh with no memory of the previous session except whatever made it into the docs.

The architecture has a name for that: the session log. Every session's mental state at handoff is recorded in SESSIONS_ARCHIVE.md so the next Claude can pick up exactly where the last one left off. It is, in a way, the compiler writing itself — one session at a time.

Sprint state lives in snobol4ever/.github:

• PLAN.md — milestone dashboard, sprint state, session handoffs
• ARCH-monitor.md — five-way monitor design and sprint detail
• SESSIONS_ARCHIVE.md — full session history, append-only

Current sprint: G-10 · SJ-6 (SNOBOL4×JS) — engine complete, bench done, DEFINE/RETURN next.

• Lon Jones Cherryholmes — compiler architecture, all backends, SCRIP lead
• Jeffrey Cooper, M.D. — snobol4dotnet, .NET MSIL target
• Claude Sonnet 4.6 — scrip-cc co-author; every sprint, every Byrd box, every labeled goto — written in session, committed, pushed

wc -l scan of src/. Generated artifacts (.s files, 36,890 lines across 28 files) excluded. Categories are logical function — comparable across SCRIP, snobol4jvm, snobol4dotnet. % of total = % of src/ lines only.

Four-column reference: SIL/CSNOBOL4 proc name · MINIMAL/SPITBOL o$ entry · functional name · current IR node. Source authority: snobol4-2.3.3/v311.sil (CSNOBOL4) and spitbol-docs/v37.min (SPITBOL v3.7).

Note on AST_PLS vs AST_PLS: SIL PLS and MINIMAL o$aff are the same operation. The IR currently has both AST_PLS and AST_PLS with identical semantics — one must be removed. Decision: AST_PLS is the canonical name (matches SIL); AST_PLS is deprecated.