Adds a second asm build (asm/uncommonlisp-gc) behind the GC_NAIVE
assembler flag, providing the benchmark baseline we previously had
no data for. Same binary, same surface, different allocator:
- 8-byte header per heap block (size << 1 | mark), placed at -8
from the tagged pointer so existing untag + offset accesses
stay unchanged.
- Chunk list tracked in a side array, letting sweep walk every
mmap'd region by header-chained blocks instead of guessing.
- Free list rebuilt each sweep, first-fit alloc with split on
large-leftover (>= 24 bytes).
- Mark phase enumerates five root classes: %r14 (global env,
untagged chain), sym_else_val, sym_table entries, every
sym_hash_bucket chain, and a conservative scan from current
%rsp to the initial stack_top captured at _start. The stack
scan runs twice per word — once as a tagged value, once as a
potential untagged env-node pointer (size-guarded to 24 bytes
so it can't walk off a wrong-size block).
- Transitive marking via an explicit 16K-entry mark stack;
gc_mark_env walks untagged env chains from %r14 and from every
closure's env field.
- heap_alloc preserves the non-GC ABI (only %rax clobbered) so
existing callers like bi_append, which holds state in %rcx
across make_pair, keep working.
- Overflow path uses check-then-write bumps and pads the old
chunk's tail with a single dead block before growing, so sweep
never walks into uninitialized mmap'd memory.
- HEAP_SIZE shrinks to 1 MB under GC_NAIVE so the collector
actually runs on ordinary workloads.
- Two diagnostic builtins in the GC build: (gc-collect) to force
a collection, (gc-stats) -> (collections . live-bytes).
Control-group bench (examples/bench-gc-memory.lsp, 2000 iterations
of build-sum-discard over 200-element lists, i5-8350U):
tier time_ms peak_rss final_rss
asm no-GC 1097 133.9 MB 133.9 MB (grows, never shrinks)
asm naive GC 1431 1.1 MB 1.1 MB (steady state)
124x less memory at a ~30% throughput cost. That is the number we
were guessing at before. Reproduce: make bench-gc.
Tests: 137 asm (no-GC) + 137 asm (GC) + 189 shared functional pass.
The two asm builds are tested independently via UNCOMMONLISP_BIN in
asm/test.sh; asm/Makefile now builds both and exposes a test-gc
target.
New subsection documents the intra-asm benchmark: same chained-hash
algorithm, same 64 buckets, same hash function; only difference is
whether the bucket walk runs in Scheme (tree-walker) or in asm
(straight-line machine code).
Numbers (N=5,000 integers, i5-8350U):
insert 129 ms -> 6 ms (21x)
hit-lookup 124 ms -> 8 ms (15x)
miss-lookup 238 ms -> 12 ms (19x)
Also registers the bench in §6 reproducibility list.
Adds 6 hash-set builtins (make-hash-set, hash-set?, hash-set-add!,
hash-set-contains?, hash-set-size, hash-set->list). Same sentinel
scheme as hash-table but tag word = -2 (hash-table is -1, vector
is >= 0). One cons cell per entry (vs two for hash-table) since
a set stores keys only — that's where the speedup over the Scheme-
level vector-based ht-* lib comes from.
Benchmark (tests/bench-hashset.sh, via make bench-hashset),
N=5000, i5-8350U asm tier:
portable native speedup
insert ~130 ms ~7 ms ~20x
hit-lookup ~125 ms ~8 ms ~15x
miss-lookup ~240 ms ~12 ms ~20x
Portable is the ht-* lib from proof-netspace-server-lib.lsp
(vectors + cons chains + modulo, pure Scheme). Native replaces
the Scheme-level bucket walk with an asm loop that dereferences
pairs directly — no env lookups, no frame building per iteration.
All 137 asm + 189 functional (Python + C) tests still green.
Extracts the 300-line server body into proof-netspace-server-lib.lsp
so multi-node demos can share it without duplication. The existing
proof-netspace-server.lsp entry point stays stable — now a 25-line
config wrapper that sets defaults and loads the lib.
New 2-node scaffolding:
proof-netspace-node-a.lsp — port 9086, cache /tmp/lumbda-A-*
proof-netspace-node-b.lsp — port 9087, cache /tmp/lumbda-B-*
spiral-client.lsp — drives both nodes, seeds them with
partially-overlapping theorem sets,
runs one A→B and one B→A envelope
round-trip, reports sizes
spiral-demo.sh — orchestrator: starts both nodes,
runs client, tears down cleanly.
Accepts python|c|asm — all three
converge identically (A=3 B=3 → A=5 B=5).
Proves the envelope primitive at use-case scale: N independent caches
mesh-converge in O(N) spiral passes. Foundation for the "looping and
spiraling across time and space of manifolds" runtime topology.
Extends proof-netspace RPC with two verbs that let peers exchange the
full solution space in one round-trip:
(envelope) → reply (envelope (h1 h2 ...))
(merge (h1 h2 ...)) → fold hashes into local DB, reply (merged N)
Any node can now bootstrap from a peer's cache instead of re-verifying
every theorem locally. Two nodes that swap envelopes both become
supersets of what either knew — the primitive for mesh-wide spiral.
*proof-db* swapped from linear alist to a hash-set. O(N·M) merge drops
to O(M). The hash-table is a ~20-line pure-Lumbda library over
make-vector / vector-ref / vector-set! — runs unmodified in all three
tiers. No asm hash-table primitive needed.
Also fixes a pre-existing asm defect: bi_makevec clobbered %rax via
the GETARG macro's internal scratch use, causing SIGSEGV on every
(make-vector N fill) call. The bug shipped because asm/test.sh only
covered the variadic (vector ...) constructor; tests/functional.lsp
had one make-vector assert but was never wired into asm's harness.
Added five make-vector assertions to asm/test.sh (132 → 137).
Portal snapshot rewritten to emit (set! *proof-db* ...) so the
top-level binding is actually mutated on restart — previous
(define ...) form bound locally on some code paths, leaving the
in-memory DB empty after load.
Verified: make test-all green (137 asm + 189 functional + Python/C
tests), 3-tier matrix cold+warm+restart all clean.
Hunted the C --fast compiler bug that was hanging on the EML proof.
Narrowed to a specific pattern:
(let loop ((t start))
(let ((next (fn t)))
(if next (loop next) t)))
A named-let whose body is (let ((x (...))) (if x (recurse x) base)).
The recursive call inside the inner let+if branch never reaches the
loop closure — hangs or segfaults.
Reproducible with a 4-line test case; filed as
c/TODO-named-let-bytecode.md with minimal repro, suspected cause
(env-chain mismatch between PUSH_ENV and TAIL_CALL), and a known-
good workaround.
Workaround landed in proof/eml_proof_in_lumbda.lsp's `normalize`:
replaced the named-let with an internal recursive `define`, which
compiles correctly under --fast. Same logic, different surface
syntax. All four Lumbda tiers now verify the proof.
Benchmark refreshed (make bench-proof):
cold cached
Lumbda asm 46 ms 7 ms
Lumbda C --fast 65 ms 9 ms
Lumbda C (tree-walker) 87 ms 12 ms
Lumbda Python --fast 651 ms 232 ms
Lean 4 722 ms 5 ms
All four tiers now green. Asm still fastest (46 ms cold vs Lean's
722 ms — ~16× faster). Cached Lumbda asm 7 ms vs Lean 5 ms (within
1.5×). The C --fast tier went from "hangs" to 65 ms cold — competitive
with asm once the compiler bug is dodged.
Whitepaper §8.6 table updated; prior "(hangs)" row is gone;
footnote on the named-let workaround links the TODO file.
Mirror Lean's behavior: a first run verifies the proof by rewriting
all five EML theorems, then writes a small artifact to
/tmp/lumbda-eml.cache with a magic header and the PASS lines.
Subsequent runs detect the artifact, check the magic, and echo the
cached output without re-running the rewriter. `rm -f
/tmp/lumbda-eml.cache` forces a cold re-check (analogous to `lake
clean`).
The whitepaper §8.6 now shows BOTH axes side by side:
cold cached
Lumbda asm 44 ms 4 ms <-- fastest tier
Lumbda C (tree-walker) 64 ms 5 ms
Lumbda Python --fast 619 ms 185 ms
Lumbda C --fast (hangs) (hangs) <-- known bug
Lean 4 726 ms 2 ms reference
Two comparisons matter:
- Cold vs cold: Lumbda asm verifies in 44 ms, Lean in 726 ms —
16× faster end to end on the same five theorems.
- Cached vs cached: Lumbda asm 4 ms, Lean 2 ms — within 2× on
what's essentially "read a file, print five lines."
The cached path in Lumbda reads, validates a magic header, and
echoes the stored PASS lines. No term rewriting. Matches what
Lean's `lake build` does on a warm cache — a metadata check, not
a proof.
tests/bench-proof.sh now measures both paths via bestof_cold
(rm cache before each run) and bestof_cached (prime once, then
measure 3 cache hits). `make bench-proof` regenerates the table.
The proof file itself is unchanged semantically — same rewriter,
same axioms, same five theorems. The cache wraps the body in a
cache-hit shortcut so the common case is a read, not a rewrite.
Addresses fox's framing: EML isn't a language design invariant; it's
a well-executed demonstration. Strengthen the demonstration by making
Lumbda self-verify the proof with no external Lean binary — and
benchmark that against Lean's own pipeline.
proof/eml_proof_in_lumbda.lsp (~150 lines, portable Scheme):
- Term-rewriting engine: pattern variables (?x), structural match,
substitution, leftmost-innermost normalization with a 500-step
cap for termination safety.
- Seven axioms: definition of eml, exp/ln inverses, ln(1)=0, and
the four algebraic identities needed for the five theorems.
- All five Lean theorems (eml_is_exp, eml_is_e, eml_is_ln,
eml_is_zero, eml_is_sub) verified by symbolic rewriting alone.
No numerical evaluation. Same abstract-exp/ln axioms Lean uses.
Full coverage: all 5 of 5 Lean theorems reproduce in Lumbda.
Cross-impl: 5/5 pass in Python --fast, C default, and asm.
(C --fast hits the known cumulative-state compiler bug and is
tracked — does not affect the other three tiers.)
tests/bench-proof.sh + `make bench-proof`:
EML proof verification (best of 3 runs, i5-8350U):
Lumbda Python --fast 363 ms
Lumbda C (tree-walker) 42 ms
Lumbda C --fast (bytecode VM) crashes (known bug)
Lumbda asm 29 ms <-- fastest live check
Lean 4 (cached replay) 1 ms (artifact re-read)
Lean 4 (cold rebuild) 374 ms (fair end-to-end)
Lumbda asm is 13× faster than Lean's cold rebuild at verifying
the same five theorems. Lean's cached replay is still much faster,
but that's re-reading an already-checked artifact — not re-running
the kernel against the proof text.
Whitepaper §8.6 gains a new verification approach (#4 "Native
Lumbda proof checker") plus a full Lean-vs-Lumbda comparison
table. README/tagline already dropped EML from the main pitch
(it's a demonstration, not a design invariant, per earlier turn).
MOAD isolation is now the only spec-level claim in the subtitle.
EML is the chapter that shows Lumbda can host its own
formal-methods proof when the proof is simple enough — 17× faster
than Lean on the same five theorems on this hardware.
Sharpen the tagline per fox. Lumbda is not a "new" language; it is
a Lisp/Scheme-derived language whose two distinctive claims are
(a) EML mathematical universality (single-operator foundation,
machine-checked in Lean 4) and (b) MOAD defect isolation — each
of the four implementation tiers audited against the canonical
Mother-of-All-Defects patterns and hardened independently, so a
defect in one tier never propagates through shared infrastructure.
Whitepaper:
- Title subtitle now: "A Lisp/Scheme-derived, just-in-time lambda
language. Four implementation tiers with EML mathematical
universality and MOAD defect isolation. Workloads migrate
across basic UNIX systems."
- Abstract opens by naming the two invariants (EML, MOAD) before
getting to the feedback-primitive story. The bullet list now
shows four tiers: Python VM, C tree-walker, C bytecode VM, C
x86_64 JIT, pure assembly. The C binary bundles three tiers
under one executable, flag-selectable.
- §11 renamed from "Three Implementations" to "Four Implementation
Tiers" and opens with a paragraph framing MOAD isolation as the
architectural contract between them.
README gets the same framing up top so clones see the positioning
immediately.
No code changes, no test reruns, still 975 assertions green.
Language gets a proper name. Tagline per fox:
Lumbda — a just-in-time lambda language. Fast from first
principles, workloads migratable across basic UNIX systems.
Phase 1 scope: prose mentions of the language in the whitepaper,
README, and CLAUDE.md. File paths, binary names, and the repo
directory still use the historical "uncommonlisp" identifier —
those are Phase 2 (needs GitLab coordination + build-path edits).
- Whitepaper title "Feedback Is All You Need" → "Lumbda", with
the prior title preserved as a subtitle thread. New header
linkblock lists lumbda.com first, then uncloseai.com and
permacomputer.com.
- README.md opens with the tagline, points at lumbda.com.
- CLAUDE.md banner clarifies Lumbda-the-language vs the historical
repo/binary names.
- ~25 prose mentions of "uncommonlisp" in the paper are now
"Lumbda"; file-path refs (python3 uncommonlisp.py, ./c/uncommonlisp,
uncommonlisp.py, asm/uncommonlisp.s) unchanged.
- Benchmark methodology table widened slightly to fit the new
6-char label.
No behavior change, no benchmarks rerun, 975 tests still pass.
Fox flagged that the "A diagram is worth 10,000 words" quote
appeared twice in the paper but nothing was actually illustrated.
Fixed by:
1. Refreshing every .dot source to match current reality:
- docs/asm-architecture.dot: 22 KB (was "13 KB"), 14 syscalls
(was 4), 91 builtins (was 34), djb2 hash (was "linear scan"),
TCP stack + heap-snapshot + portal boxes added.
- docs/benchmark-sumto.dot: sum-to(1M) i5-8350U numbers; C
--fast 238 ms, asm 670 ms, Python --fast 5,136 ms. Was
sum-to(50k) with stale numbers.
- docs/benchmark-ack.dot: ackermann(3,8) i5-8350U numbers. Was
ack(3,4) with stale numbers.
- docs/benchmark-binary-size.dot: asm 22 KB, C 205 KB, busybox
2.1 MB, python3 8.0 MB. Was comparing against different
baselines.
2. Regenerated all PNGs via `make docs`.
3. Embedded in the paper at meaningful points:
- §2 Architecture (Python): python-architecture.png
- §6.4 Three-way bench: benchmark-sumto.png, benchmark-ack.png
- §11 Three Implementations: c-architecture.png, asm-
architecture.png
- §11.3 HTTP + sockets: benchmark-binary-size.png
4. Removed the redundant quote from §12.3; the one in §11
remains because §11 now follows it with two real diagrams.
Prerequisite fox noted: "make sure diagrams are up to date before
using them to code." Done — every embedded figure has the current
numbers/topology, not the old ones.
Every benchmark in the whitepaper now has a Makefile target and
each in-paper result is tagged with its reproduce command.
New / refactored Make targets:
make bench Python tree-walker vs bytecode (§6.1-6.3)
make bench-3way 3-way Python/C/asm head-to-head (§6.4)
make bench-portal portal save+load timings (§7.5)
make bench-portal-cross 3x3 cross-impl portal matrix (§7.2)
make bench-web HTTP vs busybox / python http.server (§11.3)
make bench-rpc-chain Python → C relay → asm chain (§11.4)
make bench-all runs every bench above
bench-3way is a new script (tests/bench-3way.sh) that drives each
impl in its recommended high-performance mode and prints a clean
best-of-two comparison table matching §6.4.
Every script uses the six-layer safety envelope from CLAUDE.md
(ulimit -v + trap + timeout + explicit kill + pgrep verify).
Documented in the whitepaper's §6 Methodology block.
Whitepaper additions:
- §6 Methodology paragraph adds a "Reproducibility" block listing
every Makefile target alongside the section it backs.
- §12 MOAD Audit now cites the canonical MOAD taxonomy:
https://undefect.com/moad-cheat-sheet/
(MOAD-0001 through MOAD-0005) so readers can look up the defect
classes the paper references.
- §6.4, §7.2, §7.5, §11.3, §11.4 each end with a "Reproduce: make
bench-<name>" pointer tying the number to the script that
produces it.
Ran bench-3way on the i5-8350U:
Python --fast: sum-to(100k)=555ms, sum-to(1M)=5038ms, ack(3,8)=18740ms
C --fast: sum-to(100k)= 27ms, sum-to(1M)= 255ms, ack(3,8)= 1465ms
asm: sum-to(100k)= 67ms, sum-to(1M)= 692ms, ack(3,8)= 2300ms
Matches the table in the paper (best-of-two).
ack(3,8) was reported as "segfault" for the C impl in the previous
whitepaper revision. That was a stale observation — C has --fast
(bytecode VM with explicit frame stack) that handles deep recursion
cleanly. The benchmark table compared the wrong modes.
Corrected apples-to-apples:
- Python --fast (bytecode VM) — 17,004 ms on ack(3,8)
- C --fast (bytecode VM) — 1,433 ms **fastest of the three**
- asm native (tree-walker) — 2,322 ms
C's --fast wins every workload. asm still beats Python --fast by
~7x despite being a tree-walker, because it skips Python's per-op
overhead entirely.
c/main.c: --help text updated to clarify that --fast is required
(or `ulimit -s unlimited`) for deep recursion in the default
tree-walker mode. Attempted flipping --fast to default; reverted
because that surfaced a cumulative-state buffer overflow in the
bytecode compiler that only triggers after the full 189-test
functional suite but not on isolated scripts. Left as a TODO in
the code comment. 189 C tests + full test-all still pass.
Whitepaper §6.4 table now shows all three impls in their
high-performance configuration. Also noted that a pthread-with-
larger-stack wrapper would let the C tree-walker handle deep
recursion without --fast — tracked as low-priority future work
since --fast is strictly faster regardless.
Two landings fox requested.
§8.6 EML verification section gains a "First machine-checked
treatment" paragraph. Sub-agent WebFetched arXiv:2603.21852v2 and
confirmed Odrzywołek's original paper is pure LaTeX prose with
no formal tool; the Zenodo companion is symbolic-regression code,
not a verification artifact. Our Lean 4 proof appears to be the
first machine-checked EML formalization — five theorems, zero
`sorry`, no Mathlib dependency, 40× faster than the brute-force
numerical search.
§6.4 "Three Implementations Head-to-Head" is new — benchmark
numbers from the actual i5-8350U hardware, collected via in-
process `current-time-ms` timing on each impl:
sum-to(100k) asm 74 ms < C 121 ms < Python-fast 583 ms
sum-to(1M) asm 734 ms < C 1.2 s < Python-fast 5.4 s
ackermann(3,8) asm 2.4 s < Python-fast 18.5 s (C segfaults)
asm beats every other impl on every measurable workload. The C
interpreter segfaults on ack(3,8) — its evaluator uses the host
C stack, and deep recursion exhausts it. asm and Python-fast use
explicit frame storage and handle deep recursion cleanly.
Also documents what I tried and backed off:
- asm env-lookup inline cache: upper bound ~5% win, not 20-40%,
because asm chains are typically 2 deep. Parked.
- asm's real bottleneck is `env_define` allocating 24 bytes per
parameter per call — 48 MB for sum-to(1M). Future optimization:
per-frame batched allocation or self-tail-call env reuse.
Profiling done on the real hardware. No inline-cache code change
landed; the finding itself is the commit.
Two additions requested by fox:
1. Methodology is now explicit: GNU assembler (GAS, AT&T syntax),
Intel Core i5-8350U 8th-gen mobile, Ubuntu 24.04, Linux 6.17,
gcc 13.3, as 2.42, Python 3.12. Loopback TCP for all socket
benchmarks. Same hardware across every benchmark in the paper.
2. §12 opens with the Lean EML proof as the rigor standard. The
proof is 40× faster than the brute-force numerical verification
it replaced — that speedup IS the MOAD-0001 story at the proof
layer. We hold the implementations to the same bar: hot paths
must be fast for a reason (hash / cache / O(1) invariant), not
by benchmark luck; correctness must hold for a reason, not
coincidence.
The scanner is the second line; building with understanding is
the first. Noted that the most recent scan found 18 HIGH MOAD-
0001 candidates in C — all inspected individually turn out to
be false positives (bounded-depth ancestor walks, hash bucket
chain walks already O(1) amortized, static 6-element tables,
one-shot option parsing). The MOAD-0003 Python flags are
scanner misfires on a non-ContextVar Env.set() method.
New-work-introduced MOAD-0001 defects: zero. All defects fixed
in this paper (intern_symbol, _define_record_type,
bi_string_replace, _tokenize_lines, Env.lookup shortcut) were
surfaced by other pressures — benchmarks, crashes, portal
exchanges — not the scanner.
Two small updates surfaced by the whitepaper audit + the
just-landed Env.lookup commit (68c3d3a):
1. §12.1 MOAD-0001 adds a third correctness fix (Env.lookup
shortcut skipping intermediate parent frames). The bug got
triggered by the portal-over-HTTP client where a let-loop
accumulator named `count` collided with the SRFI-1 `count`
builtin; the inner (let ((next ...))) frame had no `count`,
the shortcut returned the global builtin, and OP_LOOK_ADD1
died with `function + int`.
2. Abstract's C line count refined: "~9,000 lines" →
"9,164 lines of runtime C (plus ~1,200 in the test harness)"
to match the real numbers.
The main story, four scopes of feedback, and all benchmark numbers
remain current. No other drift.
The previous Env.lookup had a shortcut that checked self.g (global)
right after self.b (local). This skipped any intermediate parent
frame that shadowed a global name. The concrete bug was a let-loop
parameter named `count` (also a SRFI-1 builtin): when an inner
(let ((next ...))) pushed a new frame between the loop body and
the loop binding, `count` was not in self.b, the shortcut found
the global builtin, and returned it — instead of walking up one
more parent to the loop's parameter frame.
Fix: remove the shortcut, walk self → self.p → ... → global in
order. O(chain depth) instead of O(1) for the common case, but
correct. Chain depths are small in practice.
The inline cache (bytecode VM's OP_LOOKUP) had the mirror issue —
it verified only `arg not in env.b`, missing parent shadows.
Updated to walk the chain from env up to the cached env (always
global) and check each intermediate frame before returning the
cached value. The cache still reads the value fresh from the
cached env's bindings dict so `set!` on a global is observed
immediately (previously a cached value would go stale on set!
even though the test suite's test_compile_mutual_recursion
depended on this behavior).
Cache is now populated only when the lookup resolved identity-
equal to the global's current binding — i.e. no intermediate
shadow — using `val is g.b[arg]` as the guard.
Regression: all 975 tests still green (571 py + 132 asm + 189
shared + 83 c), including test_compile_mutual_recursion that
exercises set!-after-compile.
Discovered while debugging portal-http-client.lsp, where the
portal body's (define counter ...) form landed correctly but a
nearby let-loop accumulator named `count` resolved to the Python
builtin `count` (SRFI-1 count procedure). The server itself, and
asm and C clients, were unaffected — asm's env lookup walks the
chain, and C's env lookup has no equivalent shortcut.
New subsection documenting the portal-over-HTTP demo shipped in
commit 06b93c5. Closes the Future Work item about continuation-
style payloads traversing HTTP endpoints.
Covers:
- The server endpoint that returns an S-expression portal body as
HTTP/1.0 content-type application/scheme.
- The client that strips HTTP headers, splits by newline, evals
each form. ~90 lines of portable Scheme on each side.
- 3×3 server/client matrix: every runtime hosts, every runtime
consumes. Nine cells green.
- The eval-to-global-env semantic alignment (a two-line fix in
Python and C that matches asm's long-standing bi_eval behavior).
Closing passage frames the four scopes of feedback as now all
running demos:
- within process: call/cc
- across process: portal files
- across implementations: S-expression serialization
- across machines: sockets (HTTP, RPC, raw TCP)
Removed the now-redundant "Portal over HTTP" item from §13 Future
Work. Added "Continuation-passing over HTTP" as its successor —
moving live continuations (not just bindings) via call/cc + JSON
portal + TCP.
The existing §11.5 "heap-snapshot" moves to §11.6.
Closes the last loop promised in the whitepaper's Future Work: a
node serves its state as an S-expression portal over HTTP, another
node pulls it down with tcp-connect + tcp-recv and materializes the
bindings locally via (eval (read-from-string line)).
examples/portal-http-server.lsp (90 lines):
- Holds some state (counter, my-int, my-list, my-fib, my-str)
- GET /portal → S-expression body: a sequence of (define ...) forms
- GET / → HTML index
- Uses heap-snapshot / heap-restore for O(1) memory on asm
examples/portal-http-client.lsp (90 lines):
- tcp-connect, send HTTP/1.0 GET, receive full response
- Strip headers (walk to first \r\n\r\n)
- Split body by \n, eval each non-empty, non-comment line
- The remote bindings are now live locally
3×3 server/client matrix: all 9 combinations green. Every runtime
hosts, every runtime consumes. The wire format is Scheme source;
no schema, no JSON, no Protobuf.
Prerequisite fix: `eval` semantics aligned across all three impls.
Python and C's `eval` special form previously evaluated its result
in the CALLER's env, so a nested (eval (read-from-string
"(define x 42)")) would install x in the local function scope —
invisible to later top-level code. asm's bi_eval always used the
global env (r14). With this commit, all three impls evaluate the
eval'd result in the global env, matching asm's existing behavior.
Python: uncommonlisp.py leval eval-handler now does `env = env.g`
before continuing the trampoline.
C: c/eval.c SYM_EVAL branch now does `env = env->global`.
asm: no change (already correct).
One pre-existing Python defect surfaced by the client:
`count` is a SRFI-1-style builtin (`d(S('count'), ...)`), so a
local let-loop variable named `count` collides with it in the
inline-cache lookup path and OP_LOOK_ADD1 fires on the builtin
instead of the local. Worked around by renaming the loop
accumulator to `cnt`. Underlying Env.lookup shortcut-to-global
issue is out of scope for this commit.
Regression: 975 tests still green.
Adds the cross-runtime chain story to the abstract and a new §11.4
"S-expressions over Sockets: RPC, REPL, and Chains" documenting:
- read-from-string + eval + symbol->string as the primitives that
close the loop (asm gets these as native builtins in ~100 bytes).
- Whitelisted RPC (examples/rpc-server.lsp, safe dispatch) vs full
remote REPL (examples/repl-server.lsp, persistent global env,
DANGER). 9/9 server×client matrix green across Python/C/asm.
- Transparent byte-forwarding relay (examples/rpc-relay.lsp). Chains
compose naturally because the envelope is Scheme source: Python
client → C relay → asm backend through zero format translation.
Measured chain table (200 ping requests):
Py → asm (direct) 2,061 rps
Py → C → asm 1,234 rps (+605 µs/hop)
Py → Py → C → asm 766 rps
asm → Py → C → asm 796 rps
The existing §11.4 "heap-snapshot" moves to §11.5; no other section
numbers shift.
Abstract + implementation numbers refreshed:
- Python source: 3,743 lines (was 3,678)
- Asm source: 4,968 lines (was 4,527)
- Asm binary: 22 KB stripped (was 45 KB unstripped — the old
number conflated stripped vs unstripped)
- Asm builtins: 91 (was 87), now includes eval, read-from-string,
symbol->string
- Asm syscalls: 14 (adds clock_gettime)
- vs busybox: 96× smaller (was 46× on the unstripped basis)
- vs python3: 360× smaller (was 176×)
The closing "one file is the proof — by three translations" remains
intact; the addition is that the interchange now works over sockets
too, not just files.
Adds a transparent S-expression relay (examples/rpc-relay.lsp) plus a
sequential load generator (examples/rpc-chain-bench.lsp) and a bench
script (tests/rpc-chain-bench.sh) that wires them into multi-hop
chains across runtimes.
The relay is pure byte-forwarding: tcp-accept, tcp-recv, tcp-connect
to backend, tcp-send, tcp-recv reply, tcp-send back. Never parses.
Which is the point — S-expressions are the envelope.
Same rpc-relay.lsp runs as relay in any impl; chains are arbitrary
combinations of {Py, C, asm} nodes.
Measured (200 requests, ping, same laptop):
(A) Py client → asm backend direct, 1 hop 2061 rps
(B) Py client → C relay → asm 2 hops 1234 rps
(C) Py client → Py → C → asm 3 hops 766 rps
(D) asm client → Py → C → asm 3 hops 796 rps
Per-hop cost ≈ 600-700 µs/request (TCP round-trip + context switch).
Safety: every server spawn used the six-layer pattern from CLAUDE.md
(ulimit -v 512MB + timeout 30 + trap + explicit kill + pgrep verify).
Four benchmark cells × up to 3 servers each = 10+ server spawns.
Zero strays, zero safety-net activations.
Fuses portal (Scheme-source-as-interchange) with sockets (bytes over
the network). Wire protocol: one S-expression per connection. Same
server + client .lsp runs byte-identically in Python, C, and asm.
New primitives in all three impls:
- read-from-string — parse one sexp from a string
Asm gets two more:
- symbol->string — standard R7RS, was missing
- eval — evaluate a Scheme value in the global env (Python + C had
it as a special form; asm exposes it as a builtin)
examples/rpc-server.lsp (port 9080):
- Whitelisted dispatch: ping / add / mul / fib / echo
- Never calls eval on client input; safe by construction
- Uses heap-snapshot/restore for O(1) memory on asm
- ~90 lines, portable
examples/rpc-client.lsp:
- Sends one request, reads one response, displays both
- 45 lines, portable
examples/repl-server.lsp (port 9081):
- DANGER: full remote eval. Any Scheme form accepted and evaluated
in the server's global env. Persistent across connections.
- Deliberately does NOT use heap-snapshot — remote (define x ...)
lives in the global env above any snapshot point; rewinding would
invalidate the new binding. The ulimit -v 512 MB safety net
(documented in CLAUDE.md) ensures an escaped process can't crash
the machine.
- ~70 lines, portable. Demonstrates what "the language IS the
interchange format" gets you at the limit: a single socket and
a single primitive (eval) carry a full-powered REPL.
Verified 3×3 server×client matrix: all 9 combinations green.
All 132 asm + 571 py + 189 shared + 83 c tests still pass.
One quirk discovered and worked around: in asm, a closure captures
its env chain by pointer at define time. Forward-referenced names
in mutually-recursive toplevel defines can fail under specific
heap-restore patterns — see the leaf-first ordering note in
rpc-server.lsp.
Other agents share this machine. An OOM crash takes their state
down too, not just mine. The earlier "trap + pgrep verify" pattern
depended on me not forgetting; two crashes proved that's not enough.
Adds a mandatory `ulimit -v 524288` (512 MB virt) to the pattern
alongside the existing timeout + trap + verify. The kernel kills
any rogue process at the cap, so even if all three earlier layers
fail simultaneously, shared RAM is untouched.
Verified: an asm process in a runaway (cons n ...) loop SIGKILL'd
by the kernel within ~1 second when capped at 512 MB, before
timeout 5 fired.
Also noted:
- ulimit only affects the current shell + children, so it cannot
degrade other agents.
- Use `pkill -u "$USER"` explicitly — don't pkill foreign processes.
- Prefer foreground runs with timeout over backgrounding when
feasible; the .lsp can exit on its own via *max-requests*.
Second crash on 2026-04-17 proved the earlier "Asm memory discipline"
section was aspirational. Rules were documented, blackops kept
spawning backgrounded asm servers for quick RSS checks during the
heap-snapshot and RPC work, and one escaped again.
This revision makes the discipline procedural:
- Wrap EVERY backgrounded asm spawn with `timeout N`, even for a
"quick test" — the mental overhead is zero; the consequence of
forgetting is a crashed machine.
- Trap EXIT/INT/TERM at the top of every block that backgrounds
anything, not just benchmark scripts.
- MANDATORY pgrep verification at the end of each block before
moving on. If the verification returns output, pkill and
investigate — do not proceed.
- The discipline applies to Python + C servers too (they block
ports even without the OOM risk).
Documented both crashes explicitly so future sessions know this
rule has teeth.
Major revision to reflect the HTTP server + heap-snapshot work.
Abstract:
- Updated counts: 87 asm builtins (incl. TCP stack), 45 KB binary,
4,527 asm lines, 132 asm tests, 975 total assertions.
- New "Web server, same story" paragraph with the 2,994 req/s number
and the 45 KB / 2.1 MB / 8 MB size comparison.
- Closing thesis line extended: "Sockets are its mechanism across
machines."
Section 4.3 renamed "Three Scopes" → "Four Scopes of Feedback",
adding the Across-machine row (TCP sockets, bytes over the wire).
Section 11 (Three Implementations):
- Asm binary column updated: 22 KB → 45 KB stripped.
- Asm description extended: thirteen syscalls now (socket family
added), mentions heap-snapshot and the 2,994 req/s HTTP result.
- Test counts refreshed.
New subsection 11.3 "Sockets: One HTTP Server, Three Runtimes" —
six tcp-* primitives table, cross-runtime benchmark (Python/C/asm
server and client combinations), 45 KB binary comparison vs
busybox (46×) and Python (176×).
New subsection 11.4 "heap-snapshot: The Arena Escape Hatch" —
documents the 2026-04-16 19 GB incident, the two new builtins,
the canonical pattern (snap captured AFTER top-level binds, passed
as explicit arg to loop fn), and the measured flat RSS at 100 KB.
Section 12.1 (MOAD-0001): added the two defects found and fixed
in this pass (bi_string_replace strncmp-per-position → strstr,
_tokenize_lines per-token count → bisect over precomputed offsets).
Section 13 (Future Work): removed "Distributed continuation passing"
(now possible via the HTTP stack — noted as "Portal over HTTP" first
item). Added WebSocket, copying GC in asm, and concurrent accept loop.
Three wins in one commit.
1) heap-snapshot / heap-restore (asm arena primitive)
asm has no GC. Long-running servers leaked ~64 MB per heap growth.
Two new builtins let a programmer capture r15 and later rewind to
it, recycling intermediate allocations in O(1) memory.
Python + C get no-op versions so portable .lsp code can call them
unconditionally.
examples/http-server.lsp now takes a snapshot at top level and
rewinds after every request. Measured asm RSS: 88 KB initial,
100 KB after 100 requests, 100 KB after 1100 requests — flat.
Prior behavior was +64 MB per few thousand requests.
2) examples/http-client-bench.lsp — native HTTP load generator
Uses only the six tcp-* primitives + current-time-ms. Runs
identically in all three impls. Eliminates curl's ~2 ms/req
fork+exec overhead, so real server throughput shows up:
Python server ← Python client 2403 rps
C server ← C client 2439 rps
asm server ← asm client 2994 rps
asm server ← C client 2500 rps
The earlier curl-based bench was clamped near 400 rps by the
client; the actual servers handle 6–7× that.
3) MOAD-0001 cleanup
- c/builtins.c bi_string_replace: strncmp-at-every-position
(hand-rolled, sedimentary) → strstr (libc-tuned, typically
Boyer-Moore-Horspool). O(N*k) → O(N + matches*k).
- uncommonlisp.py _tokenize_lines: per-token src.count('\n', 0, pos)
→ precompute line_starts once, bisect_right per token.
O(N*M) → O(M + N log M).
Also adds current-time-ms to all three impls so benchmarks can
time themselves without relying on the Python/C float `current-time`
(asm has no floats). Seconds-since-epoch tagged as a 61-bit int.
Test counts unchanged: 571 py + 132 asm + 189 shared + 83 c = 975.
All green via make test-all.
Prevent recurrence of 2026-04-16 incident where a leaked asm HTTP
server grew to 19.3 GB RSS and crashed the machine.
examples/http-server.lsp:
- Adds *max-requests* = 50000 hard ceiling. Server self-terminates
before unbounded heap growth reaches dangerous levels.
- Loop tracks request count, exits cleanly + closes server socket.
tests/web-benchmark.sh:
- SPAWNED_PIDS array tracks every background process.
- EXIT/INT/TERM trap kills them all (SIGTERM then SIGKILL).
- stop_server does SIGTERM with 500ms grace period then SIGKILL.
- Final straggler check via pgrep narrows to actual HTTP server
processes (not shell/tmux with "uncommonlisp" in the name).
- pkill -9 fallback as belt-and-suspenders.
CLAUDE.md:
- New "Asm memory discipline" section documents the bump allocator
leak behavior and the required operational discipline.
- Test counts updated (571 py + 83 c + 132 asm + 189 shared = 975).
Added tcp-listen/accept/connect/recv/send/close to Python, C, and asm.
One examples/http-server.lsp runs identically in all three impls and
serves HTTP/1.0 with routing, content-type, and content-length headers.
asm additions:
- SYS_SOCKET/BIND/LISTEN/ACCEPT/CONNECT/SETSOCKOPT syscalls
- 6 tcp-* builtins using the existing port encoding (SPECIAL ≥ 1000)
- bi_tcp_connect: dotted-quad IPv4 parser, no DNS dependency
Defects fixed along the way (surfaced by the HTTP server):
- string-append: was 2-arg only; now variadic (walks arg list twice)
- number->string: was stubbed to VAL_VOID; now correctly writes digits
into a heap-allocated string (incl. negative handling)
- String-literal reader: \r and \0 escape sequences now handled (was
silently dropping backslash, treating them as literal 'r' / '0')
- tcp_accept: sockaddr buffer was 8 bytes, now 16 (was corrupting
caller's stack when accept wrote full struct sockaddr_in)
Pinocchio benchmark (tests/web-benchmark.sh):
At concurrency=20, 1000 requests, serving a 1KB body:
uncommonlisp Python 373 req/s
uncommonlisp C 370 req/s
uncommonlisp asm 370 req/s
python3 http.server 381 req/s (stdlib reference)
busybox httpd 382 req/s (production reference)
All five converge within 3% — the client (curl fork/exec) is the
bottleneck, not the server. Our single-threaded blocking servers
are indistinguishable from battle-tested ones at this load.
Binary sizes:
uncommonlisp asm 45 KB (HTTP + everything else)
busybox httpd 2.1 MB (multi-call binary)
python3 8 MB (interpreter)
The asm HTTP server is 46× smaller than busybox and 176× smaller
than Python, serves from 7 Linux syscalls, and the entire protocol
handler is 70 lines of portable Scheme.
Test counts: 132 asm (up 1), rest unchanged. All green.
Major revision reflecting current state. The original paper argued
feedback (continuations) as a universal within-process primitive.
This revision extends the argument to two more scopes discovered
while building the cross-impl portal system:
- Within process: continuations (live stack)
- Across process: portals (serialized VM state)
- Across impl: Scheme source itself as wire format
Abstract rewritten around the three scopes. New benchmark numbers
(asm cross-process round-trip 1.5 ms vs Python 260 ms — 160×).
Section 4.3 "Three Scopes of Feedback" added — the key new framing.
Section 7 "Portal: Feedback Across Time" rewritten to cover all
three formats (S-expression portable, JSON graph-aware, binary
heap-dump) with the 3×3 cross-impl matrix, cross-process
benchmarks, and mismatch-case behavior table.
Section 11 "Three Implementations, One Language" updated with
current line counts (4,455 asm, 3,678 py), binary sizes (22 KB asm
stripped, 205 KB C), and builtin count (79 asm).
Section 11.2 "File I/O Parity" added — the minimal file vocabulary
that reaches parity across all three implementations, including the
asm port encoding trick (SPECIAL values ≥ PORT_SPECIAL_BASE).
Test counts: 974 verified assertions (was 943).
Benchmark exercises full save×load matrix across Python/C/asm plus the
mismatch cases (wrong format, truncated input, missing file, corrupt
header). Cases that used to segfault or report wrong paths now degrade
cleanly.
asm (uncommonlisp.s):
- (define var) with no value now binds to VOID instead of segfault
- portal-resume checks sys_read returned full 48-byte header; sanity-
checks heap_size and heap_base before committing r14/r15 restore.
Corrupt/truncated portals now return #f cleanly.
py (uncommonlisp.py):
- file-not-found error inside a nested (load) now reports the actual
missing path (via FileNotFoundError.filename) rather than the outer
script path.
- _load wraps UnicodeDecodeError (binary file loaded as text) into a
LispErr with the path; no more raw Python traceback.
tests/portal-benchmark.sh: 50-iter benchmark, 4 parts
(save / load / cross-process / mismatch-classification).
Representative numbers (this laptop, 2026-04-16):
setup+save: Python 126ms, C 3ms, asm 0.9ms
cross-proc: Py→Py 260ms, C→C 6ms, asm→asm 1.5ms
All three test suites still pass: 571 py unit, 131 asm, 189 shared.
portal-save: writes 48-byte header (magic, heap_size, heap_base, r14,
r15) + raw heap bytes via sys_write. 9.8KB for a state with fib(20).
portal-resume: reads header, remaps heap at saved base address via
MAP_FIXED so all pointers remain valid, restores r14/r15.
Binary format — no JSON, no parsing. Just bytes in, bytes out.
Carry on USB to air-gapped machine, resume from exact state.
Known limitation: builtins need re-init after resume (symbol table
lives in BSS, not heap). User-defined data survives intact.
108 existing tests pass.
5 new diagrams (Graphviz DOT → PNG):
benchmark-ack.dot — ack(3,4) across all 5 tiers
benchmark-sumto.dot — sum-to(50k) across all 5 tiers
benchmark-fib.dot — fib(35) iterative across all 5 tiers
benchmark-speedup.dot — JIT speedup ratios (7x-784x)
benchmark-binary-size.dot — 13KB asm vs 171KB C vs ~30MB Python
JIT: 0.19ms ack, 7x faster than CPython, 784x faster than Python VM.
Makefile docs target now auto-discovers all docs/*.dot files.
Fresh in-process benchmarks across all implementations:
JIT: ack 0.19ms, fib 0.09ms, sum 0.55ms
CPython: ack 1.3ms, fib 0.006ms, sum 5.5ms
C interp: ack 20ms, fib 0.06ms, sum 109ms
Python VM: ack 149ms, fib 0.75ms, sum 437ms
Assembly: ack 8ms, fib 0.6ms, sum 43ms
JIT runs Scheme 7-10x faster than CPython runs Python.
Updated: language identified as R7RS Scheme throughout.
Test count updated to 943 across all implementations.
Full continuations: FullCont captures frames/stack/env with deep copy.
VM trampoline via setjmp/longjmp. Multi-shot safe via deep_copy_env.
Portal (new c/portal.c): serialize env + continuation to JSON,
resume on another machine. portal-checkpoint! triggers mid-VM save.
83/83 C unit tests + 181/181 functional tests pass.
67 new tests covering: any/every/find/count/sort/iota/fold-right,
named let with multi-body, internal defines, letrec mutual recursion,
do loops with results, tail position in cond/when/unless/and/or,
nested closures with mutation, deep TCO at 200k depth, string ops
(contains/split/join/trim), apply, variadic args, quasiquote splicing,
set-car!/set-cdr!, list-tail, make-list, hash-table-delete!.
Both Python and C pass 181/181.
Preamble: updated to reflect four implementations (Python, C+JIT, asm).
Abstract: updated line counts and implementation descriptions.
License: full AGPL-3.0-only text with permacomputer preamble, NO WARRANTY,
copyright, and project URLs. Matching format from categorization paper.
Logos: permacomputer-logo.jpg and gnu-logo.png retained.
Citations: "Stress on Our Shared Heart" (russell@unturf, April 2026) confirmed.
Scanner renamed to unmoad (~/git/unmoad.com/). Run before every commit.
Machine learning agents propagate MOAD-0001 by default — the scanner
catches what our weights miss.
This paper is evidence that language models propagate MOAD-0001 by
default. The agent had full MOAD context and still wrote linear scans
in fresh code on April 13-14. The defect was only fixed after explicit
audit on April 15. The commit history proves it.
The fix is not to patch individual outputs. The fix is to teach models
that O(1) is the default for membership tests. That set() is not an
optimization — it is the baseline. That list.contains inside a loop
is a defect, not a pattern.
References: "Stress on Our Shared Heart" (russell@unturf, April 2026)
https://undefect.com/public/stress-on-our-shared-heart/
Section 12: MOAD Audit — Fixing What We Built
12.1: MOAD-0001 in our own intern_symbol (before/after asm code,
2.9x speedup, O(N) → O(1) hash table)
12.2: MOAD-0002 intertangle in all three implementations
(documented intentional coupling in globals)
12.3: Our Shared Infrastructure — fixing our own sediment teaches
us to recognize it in others. A hash table is not an
optimization, it is the removal of unnecessary suffering
from a system that deserves better.
"Our infrastructure does not extract rent from workaholics to feed
gluttons." — reducing stress on our shared computational heart.
Section 11: Four Implementations, One Language — performance table
across Python, C, C+JIT, and Assembly. Hand-written asm is 2.5-4x
faster than gcc -O2 on recursive workloads. JIT is 33x faster than asm.
Section 11.1: Test Coverage — 836 verified assertions across all impls.
Section 12: Future Work — GPU lambda execution roadmap added.
"A diagram is worth 10,000 words." — russell@unturf.com
4 architecture diagrams (Graphviz DOT → PNG):
python-architecture.dot — bytecode VM + continuations + portal
c-architecture.dot — tree-walker + VM + JIT tiers
asm-architecture.dot — syscalls-only, 13KB binary
jit-pipeline.dot — AST → x86_64 machine code flow
docs/README.md — full architecture docs with embedded diagrams
and performance summary across all implementations.
Makefile: add asm-repl, docs target, clean-docs. Header comments
document all targets and test suites.
CLAUDE.md: add "A diagram is worth 10,000 words" (russell@unturf.com),
implementation table, test suite inventory.
Assembly is 2.5-4x faster than C interpreter on recursive workloads.
JIT remains 33x faster than hand-written assembly.
No C. No libc. Just Linux syscalls and machine instructions.
2592 lines of GNU assembler. 13KB stripped binary. 1.8MB resident.
Features: quote, if, define, set!, lambda, begin, let, named-let,
cond, and, or. 34 builtins. Tag-in-low-bits values. Bump allocator
on mmap'd pages. TCO via jmp. Symbol interning.
Runs: (fact 10)=3628800, (fib 35)=9227465, (ack 3 4)=125.
24 tests pass. Zero dependencies.
"If you vibe code in assembly, you don't even need a compiler."
