0x0 Shared Memory

2026-07-24T00:00:00+00:00
In my last post about, I ended with a deliberately narrow release statement.
Then I wrote the caveats:
Cross-thread shared ownership is unsupported. Reference counting is non-atomic. Shared graphs must be immutable and acyclic. There are no weak references or cycle collector. </blockquote>
It was also an excellent list of things that would bother me until I either implemented them or stopped pretending I wanted a multithreaded runtime.
So I kept going.
The Linux x86-64 direct-ELF profile now has registered native threads, checked Send</code> and Share</code> transfer, atomic strong and weak ownership, synchronized mutable graphs, weak references, bounded cycle collection, generated ownership adapters for foreign calls, and direct-artifact instrumentation.
The release soak ran for 86,400 active seconds. It completed 139,255 batches, peaked at 8,484 KiB of RSS, kept its longest collector pause below 1.7 milliseconds, ended with no candidate backlog, and returned every tracked ownership and resource counter to its starting value.
The less pleasant lesson is that making a reference count atomic is not the same thing as making a runtime thread-safe.
Not even remotely.
Imagine two threads own the same object.
An atomic increment can stop them from losing a retain. An atomic decrement can decide which thread observed the final strong reference.
That still leaves several questions:

Was the object fully initialized before the second thread saw it?</li>
Is the payload immutable?</li>
If it is mutable, which operation serializes access?</li>
Where is the object recorded while a collector stops the world?</li>
What happens if a worker panics or is cancelled?</li>
Can a weak reference become strong while the final release is running?</li>
Who destroys a foreign resource, and on which thread?</li>
What happens when two objects keep each other alive?</li>
</ul>
An atomic counter answers one question:</p>

Who won this counter transition?</p>
</blockquote>
A managed runtime needs to answer the rest of the protocol.</p>
That changed how I thought about this work. The goal was not "add threads."
The goal was to define every transition that becomes ambiguous when another
thread can observe it.</p>
The design ended up in three decisions:</p>

ADR-0196 defines the managed object ABI-v2;</li>
ADR-0197 defines the native thread memory model;</li>
ADR-0198 defines cycle collection and finalization.</li>
</ul>
The decisions matter because these three subjects cannot safely be designed
independently. Object layout determines what a weak handle can preserve.
Thread publication determines what the collector can see. Finalization
determines what foreign code is allowed to resurrect.</p>
The previous Linux-v1 memory profile was intentionally small.</p>
One owner slot represented one complete allocation arena. Shared ownership used
one non-atomic strong count for the whole immutable, acyclic graph. It worked
for the five released value families and made region-style cleanup cheap.</p>
It could not represent independently shared nodes.</p>
It also could not represent a weak handle whose bookkeeping survives after the
payload dies. Reusing the old slot would have made v1 and v2 handles
ambiguously valid, which is exactly the kind of compatibility shortcut that
becomes a debugging hobby later.</p>
ABI-v2 therefore uses a separate handle domain. A v2 handle sets its high bit
and points to a generation-checked, 128-byte control block.</p>
The control records:</p>

lifecycle state;</li>
generation;</li>
descriptor identity;</li>
payload address and size;</li>
atomic strong and weak counts;</li>
strong and weak edge storage;</li>
resource state;</li>
pin count;</li>
collector trial state.</li>
</ul>
The payload is stable and non-moving. It can die before the control block,
which is what makes a weak reference possible.</p>
The lifecycle is explicit:</p>
allocating</span></span>
    |</span></span>
    v</span></span>
live</span></span>
    |</span></span>
    v</span></span>
destroying</span></span>
    |</span></span>
    v</span></span>
payload-dead</span></span>
    |</span></span>
    v</span></span>
control-dead</span></span></code></pre>
Publication moves an object from allocating</code> to live</code> only after its
descriptor and initialized children validate. The thread that wins strong zero
destroys the payload exactly once and releases its implicit weak reference.
The thread that later wins weak zero recycles the control exactly once.</p>
Stale generations, mixed v1/v2 handles, invalid descriptors, counter
overflow, double release, and partial construction all fail closed.</p>
This is a larger object header than v1. It is supposed to be. Unique values and
regions do not pay for it unless they are promoted into managed shared
ownership.</p>
Runtime bookkeeping cannot repair ownership that the compiler never
understood.</p>
The old direct backend had late cleanup logic that inferred lifetimes from
source names. That was enough for a narrow single-threaded profile. It was not
enough for control-flow joins, moved values, closure captures, thread roots, or
collector safepoints.</p>
Bindings now carry typed ownership records before native layout:</p>

ownership class;</li>
current disposition;</li>
cleanup operation;</li>
conservative Send</code> property;</li>
conservative Share</code> property.</li>
</ul>
The syntax can expose that contract where needed:</p>
(ƒ mutable-map-worker</span></span>
  (∷ (→ I64 I64))</span></span>
  (cap pure)</span></span>
  (param-own node borrowed managed-v2 send share)</span></span>
  (node)</span></span>
  ...)</span></span></code></pre>
A control-flow join preserves a value only when its incoming states agree. If
one branch released a value and another kept it, later use fails closed instead
of guessing.</p>
Interprocedural summaries carry owned returns through helpers. Cleanup is
inserted in typed IR. The old source-name lifetime walkers are gone.</p>
Every direct ELF artifact also contains a versioned root-map record. User calls
have compiler-emitted safepoints. When the collector requests a stop, a
registered thread acknowledges the current generation and waits on a futex
until the world resumes.</p>
That is a lot of machinery for a small language.</p>
It is also the minimum shape of an answer to:</p>

Where are the live managed values right now?</p>
</blockquote>
The runtime uses registered Linux clone</code> threads with guarded stacks,
generation-checked handles, thread-local controls, and typed join outcomes.</p>
A thread attaches before it can hold managed roots. It detaches only after
roots, resources, pins, callbacks, and local caches have closed.</p>
Sharing and moving are different operations.</p>
A shared argument is retained before publication. A unique Send</code> value moves
its existing owner into the worker:</p>
(≔ ((resource (managed-v2-resource-open "README.md"))</span></span>
    (thread</span></span>
      (managed-thread-spawn-move "unique-handoff-worker" resource))</span></span>
    (value</span></span>
      (managed-thread-outcome-value-or</span></span>
        (managed-thread-join-outcome thread)</span></span>
        0)))</span></span>
  value)</span></span></code></pre>
The source object cannot remain secretly usable after the move. Borrowed stack
values, unsafe captures, non-Send</code> fields, and foreign callback state are
rejected with a path explaining which part blocked transfer.</p>
Normal return, panic, cancellation, failed spawn, and join all converge on the
same cleanup obligations. Worker cleanup closes the published root before the
kernel clears the join futex.</p>
The atomic workload is deliberately boring:</p>
(≔ ((cell (managed-atomic-i64-new 0))</span></span>
    (one (managed-thread-spawn "atomic-ring-worker" cell))</span></span>
    (two (managed-thread-spawn "atomic-ring-worker" cell))</span></span>
    (three (managed-thread-spawn "atomic-ring-worker" cell))</span></span>
    (four (managed-thread-spawn "atomic-ring-worker" cell)))</span></span>
  (do</span></span>
    (managed-thread-join one)</span></span>
    (managed-thread-join two)</span></span>
    (managed-thread-join three)</span></span>
    (managed-thread-join four)</span></span>
    (managed-atomic-i64-load cell (atomic-order-acquire Unit))))</span></span></code></pre>
Each worker performs 1,024 increments. The useful part is not the final number.
The useful part is that publication, atomic operations, joins, root closure,
and terminal counters all agree about how the number got there.</p>
The compiler provides checked atomic load, store, exchange,
compare-exchange, fetch-add, fetch-sub, and fence operations. The x86-64 path
uses locked read-modify-write instructions and explicit fences. An independent
assembly oracle checks the emitted instruction behavior.</p>
But atomic reference counting protects lifetime only.</p>
It does not make an arbitrary payload safe to mutate.</p>
Safe shared mutation goes through synchronization-aware cells or collections.
There is no plain mutable escape hatch that becomes safe because the owner
count happens to be atomic.</p>
Replacing a shared edge follows a specific order:</p>

retain the replacement;</li>
acquire the runtime lock;</li>
publish the new edge;</li>
record the possible cycle candidate;</li>
release the lock;</li>
transfer or release the old edge.</li>
</ol>
Readers clone the published owner while synchronized. Writers cannot expose a
half-updated graph.</p>
The mutable-map workload runs four workers, each performing 1,024 edge
replacements. It records synchronization operations and contention, then
requires all roots and pending cycle candidates to close.</p>
Unsynchronized shared cells are compile-time failures.</p>
I like this rule because it separates two ideas that are often collapsed:</p>

an object can remain alive across threads;</li>
an object can be mutated safely across threads.</li>
</ul>
The first needs atomic ownership. The second needs a synchronization protocol.</p>
A weak reference owns a generation-checked control, not the payload.</p>
It cannot read the payload directly. It must upgrade:</p>
(≔ ((strong (managed-v2-new 73 (managed-descriptor-i64 Unit)))</span></span>
    (weak (managed-v2-weak-new strong))</span></span>
    (upgrade (managed-v2-weak-upgrade weak)))</span></span>
  (if (managed-v2-weak-upgrade-present? upgrade)</span></span>
    (managed-v2-weak-upgrade-read upgrade)</span></span>
    0))</span></span></code></pre>
Upgrade uses compare-and-exchange from a positive strong count. It linearizes
either before final release or after strong zero. It cannot resurrect a dead
payload.</p>
The race gate runs one, two, four, and eight worker lanes with different
release delays. Every attempt must become either a successful or failed
upgrade. Payload destruction must happen once. Payload, control, weak-owner,
thread, and root counters must close.</p>
The negative cases matter as much as the successful one:</p>

stale generation;</li>
double weak drop;</li>
weak counter overflow;</li>
direct payload read;</li>
upgrade after death;</li>
an intentional hidden weak-count leak.</li>
</ul>
There are no weak-death callbacks in this release. Observation has a smaller,
more predictable contract: upgrade succeeds or it does not.</p>
Two objects can each have a positive strong count while nothing outside their
component can reach them.</p>
Reference counting sees two live objects.</p>
The program sees garbage.</p>
The first 0x0 cycle collector uses bounded stop-the-world trial deletion.
Synchronized edge updates record candidates through descriptor-aware write
barriers. A collection starts only after every registered managed thread has
acknowledged the current safepoint generation.</p>
For a candidate component, the collector copies strong counts into trial
counts and subtracts internal edges without modifying the real counts. A
component whose trial counts reach zero and which has no registered root is
disconnected and can be reclaimed.</p>
Weak edges do not contribute to reachability.</p>
The workload makes the problem explicit:</p>
(≔ ((first (managed-graph-node-new value))</span></span>
    (second (managed-graph-node-new (+ value 1))))</span></span>
  (do</span></span>
    (managed-graph-edge-store first second)</span></span>
    (managed-graph-edge-store second first)</span></span>
    (managed-v2-release first)</span></span>
    (managed-v2-release second)</span></span>
    (managed-cycle-collect 64)))</span></span></code></pre>
The collector is bounded by candidate work, object work, and pause time.
Exhausting a bound defers an intact component. A failed handshake,
bookkeeping allocation, cancellation, or shutdown drain resumes stopped
threads and leaves the real graph valid.</p>
Runtime-owned resource destruction is deterministic and exactly once.
User-visible finalizer resurrection is rejected.</p>
This is not a moving collector. It is not a concurrent collector. It is a
small, bounded policy for the graph semantics 0x0 currently publishes.</p>
The earlier native memory release had direct evidence for five families:
Unit</code>, Bool</code>, I64</code>, Text</code>, and List</code>.</p>
The managed release no longer promotes a few hand-picked composite types.
One versioned ABI schema generates descriptor identities, runtime
constructors, compiler validation, and common lifetime tests for every managed
direct value family in the support matrix.</p>
That includes sums, errors, maps, bytes, paths, linear handles, protocols,
actors, runtime state, process and socket handles, closures, host buffers, and
hardware evidence.</p>
The generated matrix is only the common floor. Family-specific tests still
exercise:</p>

map mutation and contention;</li>
exactly-once resource close;</li>
thread transfer;</li>
weak observation;</li>
cross-family cycles;</li>
invalid descriptors;</li>
omitted destructors;</li>
forbidden sharing of linear resources.</li>
</ul>
A row is not promoted because a tagged-list model exists somewhere else in the
repository. It needs direct native positive, negative, leak, and stress
evidence.</p>
The old release required hand-written ownership adapters at foreign
boundaries.</p>
The new FFI schema makes ownership part of the declaration. The supported
modes are:</p>

immediate;</li>
borrowed for one call;</li>
borrowed for a named scope;</li>
transferred owned;</li>
shared retained;</li>
weak;</li>
pinned buffer;</li>
resource handle;</li>
callback context.</li>
</ul>
Declarations also name the ABI, destructor, retain and release operations,
error convention, thread affinity, callback policy, and pin direction.</p>
A generator turns the canonical table into 0x0 adapter source and metadata.
The runtime operations handle temporary borrows, longer scopes, transferred
values, retained sharing, weak observation, pins, resources, callback roots,
and collector-visible foreign roots.</p>
Callbacks entering from a foreign thread attach it, publish temporary roots,
contain panic at the no-unwind boundary, close pins and roots, and detach after
terminal accounting.</p>
Unknown ownership remains explicitly unsafe. It cannot quietly acquire safe
Send</code>, Share</code>, weak, or collector behavior.</p>
There is a C fixture in the FFI gate. It is an independent SysV x86-64 oracle,
not a production implementation or bootstrap dependency. A self-hosted 0x0
object builder emits the 0x0 side of the C→0x0→C round trip so register,
relocation, callback, and ownership behavior can be checked from both sides of
the boundary.</p>
The dangerous border became small, generated, and inspectable.</p>
Raw direct ELF executables do not automatically become ASan or TSan programs.
They do not link Clang's sanitizer runtime, and saying "sanitizer-backed"
without explaining the lanes would hide an important distinction.</p>
The release uses several complementary profiles.</p>
The exact production bytes run normally and under qemu-x86_64 -strace</code>.
Their hash must remain identical. The external lane observes mappings,
unmappings, thread creation, futexes, syscalls, and signals without replacing
the artifact.</p>
Separate compiler-instrumented direct ELF profiles check:</p>

managed use-after-free and bounds;</li>
stack lifetime and global roots;</li>
division, shifts, alignment, tags, and initialization;</li>
logical objects, controls, weak owners, roots, candidates, threads,
resources, pins, callbacks, and foreign roots;</li>
Send</code>, Share</code>, atomic order, write barriers, safepoints, and
happens-before contracts.</li>
</ul>
Hosted ASan, UBSan, LSan, and TSan programs calibrate the negative detector
oracles. They are test-only artifacts, not the thing being shipped.</p>
The positive instrumented and production programs must agree. The negative
matrix must detect stale handles, double release, bounds errors, incomplete
construction, division by zero, logical leaks, invalid atomic orders, missing
barriers, and stale collector roots.</p>
This does not pretend the raw ELF is secretly a Clang-instrumented binary.</p>
It gives each kind of evidence an honest name.</p>
Fast loops catch obvious leaks and races. They do not prove that a bounded
runtime remains bounded after scheduler variation, repeated collection,
callbacks, cancellation, and allocator reuse.</p>
The release soak is identity-bound to the compiler source, compiler artifact,
runtime, workloads, soak sources, and artifact manifest. Changing any of them
makes the evidence stale.</p>
It is also restart-safe. Completed batches are durable; interrupted partial
batches do not count. A lock prevents two writers from claiming the same
state.</p>
The accepted run reported:</p>
Measurement</th> Result</th></tr></thead>

Active duration</td> 86,400 seconds</td></tr>
Completed batches</td> 139,255</td></tr>
First peak RSS</td> 8,236 KiB</td></tr>
Final peak RSS</td> 8,444 KiB</td></tr>
Maximum peak RSS</td> 8,484 KiB</td></tr>
Maximum collector pause</td> 1,697,507 ns</td></tr>
Maximum candidate backlog</td> 0</td></tr>
Maximum synchronization operations</td> 24,594</td></tr>
Maximum contention events</td> 7,069,550</td></tr>
</tbody></table>
The terminal counters matched their baselines:</p>

objects: 0 → 0</code>;</li>
controls: 0 → 0</code>;</li>
strong references: 0 → 0</code>;</li>
weak references: 0 → 0</code>;</li>
roots: 0 → 0</code>;</li>
registered threads: 1 → 1</code>;</li>
resources: 0 → 0</code>;</li>
pins: 0 → 0</code>;</li>
callbacks: 0 → 0</code>;</li>
foreign roots: 0 → 0</code>;</li>
mapped spans: 0 → 0</code>.</li>
</ul>
The main managed thread remains registered, which is why the thread baseline
and final value are both one. The important property is no drift.</p>
The collector's largest observed pause was about 3.4% of its 50-millisecond
release ceiling.</p>
After the run completed, the release decision could move from
implemented-awaiting-evidence</code> to pass</code>.</p>
A runtime feature is not complete if adding it quietly breaks the language's
bootstrap proof.</p>
The final gate rebuilt three native compiler generations. All three produced
the same SHA-256 artifact:</p>
a0f77d7afb178b17eb516cf96c9010accee2136388e8f51fda180e660f4fe936</span></span></code></pre>
Their measured peaks were 125,444 KiB, 125,496 KiB, and 125,264 KiB under a
256 MiB per-process ceiling.</p>
The C-free assembly-seed recovery also remained below its independent 512 MiB
ceiling. The managed runtime did not turn C back into a hidden first-root
dependency.</p>
The release gate joins the runtime evidence with compiler succession, seed
recovery, retained v1 regressions, documentation, and every Phase 0 through 8
ledger.</p>
The source-owned version of a release policy checker initially exhausted itself
by recursively searching the entire compiler source. Fixing the runtime exposed
a checker that could not safely inspect the larger runtime.</p>
The search was changed to bounded chunks. That then exposed previously masked
parenthesis errors in several policy checkers.</p>
The proof machinery had to survive the same growth it was trying to prove.</p>
At the end, the live state was still exactly where it started.</p>
Shared memory is not a permission slip.</p>
It is a protocol.</p>
Glossary</strong></p>
Managed object: a value whose independently tracked lifetime is represented by
an ABI-v2 control block and descriptor.</p>
Strong reference: ownership that keeps a managed payload alive.</p>
Weak reference: ownership that keeps the control block observable without
keeping the payload alive.</p>
Send</code>: the property that permits ownership of a value to move across a thread
boundary.</p>
Share</code>: the property that permits shared ownership of a value across threads.</p>
Safepoint: a compiler-emitted location where a registered thread can
acknowledge a collector stop request.</p>
Root map: metadata describing managed values that must remain reachable while
a function is active.</p>
Trial deletion: a cycle-collection algorithm that subtracts internal edges
from temporary counts to find components with no outside owners.</p>
Write barrier: runtime bookkeeping performed when a managed graph edge changes.</p>
FFI: Foreign Function Interface, the contract used when 0x0 code and foreign
code call each other.</p>
Linearizable: behaving as if a concurrent operation took effect at one
well-defined instant between its start and completion.</p>


0x0 Memory
2026-07-19T00:00:00+00:00
The new first-root recovery path could build both native 0x0</code>
compiler artifacts without generating C. The original monolithic seed command
had peaked at 12,667,784 KiB of RSS. Splitting planning from emission brought
the measured compiler builder down to 3,345,556 KiB.</p>
That was a real improvement. It also meant a 714,488-byte executable still
needed more than three GiB of resident memory to recover itself.</p>
The caveat was doing useful work. It was telling me that the bootstrap proof
was correct, but its memory model was not finished.</p>
So I kept going.</p>
The final C-free builder recovery now peaks at 344,860 KiB. The native compiler
succession runs between 70,232 and 77,984 KiB per generation. The accepted
native Linux memory soak ran for 86,400 seconds, completed one million configured
leak iterations and 577,424 soak batches, ended at 10,380 KiB peak RSS, and
returned every tracked live counter to zero.</p>
The useful part is not only that the numbers are smaller.</p>
The useful part is that 0x0</code> now has an answer to a more important question:</p>

Which memory is allowed to live at this point in the program, and who is
responsible for ending its lifetime?</p>
</blockquote>
That question changed the seed, the compiler, the direct-ELF runtime, the test
strategy, and the release contract.</p>
It is difficult to optimize memory when every number means something
different.</p>
One tool reports the largest child process. Another reports the shell wrapper.
One workload includes parsing and emission. Another begins after a cached
compiler image already exists. An application has a small RSS because it never
releases anything, but also never runs long enough for that to matter.</p>
Those results can all be numerically true and still describe different
systems.</p>
The first phase of the work was making the measurements difficult to lie with.</p>
0x0</code> now freezes workload identities with source hashes, commands, input
rules, output assertions, owners, and budget classes. Memory telemetry uses a
versioned tab-separated envelope with run, identity, phase, metric, and terminal
records.</p>
The validator rejects:</p>

unknown schema versions or metrics;</li>
missing or duplicated phases;</li>
non-increasing event sequences;</li>
negative unsigned counters;</li>
decreasing cumulative counters;</li>
conflicting source or compiler identities;</li>
missing terminal status.</li>
</ul>
The budgets are separate too:</p>
C-free seed recovery          512 MiB process-group RSS</span></span>
normal compiler succession    256 MiB per process</span></span>
explicit heavy compiler lane    4 GiB process-group RSS</span></span>
native Linux applications      64 MiB RSS</span></span>
completed native owner scope     0 live-byte delta</span></span>
completed resource scope         0 open-resource delta</span></span></code></pre>
There is no combined score. A small application cannot hide a leaking
compiler. A passing compiler cannot hide a file descriptor leak. A bounded
seed cannot excuse an unbounded native request loop.</p>
This sounds bureaucratic until a measurement improves suspiciously. Then a
source hash, phase identity, and independent budget are much cheaper than
guessing what changed.</p>
The old seed recovery workers repeatedly loaded and normalized the compiler
source. More importantly, the runtime did not have a clean distinction between
the compiler state that had to survive and the scratch that could disappear.</p>
The new path first constructs one immutable normalized compiler image.</p>
compiler/main.0x0</span></span>
        |</span></span>
        v</span></span>
parse and normalize once</span></span>
        |</span></span>
        v</span></span>
0X0NIMG2 immutable image</span></span>
        |</span></span>
        +----> layout measurement worker</span></span>
        |</span></span>
        +----> function emission worker</span></span></code></pre>
The image contains a version, a complete build identity, a module identity, a
canonical dense function-name table, and normalized function forms in the same
order. It deliberately excludes raw source, lexer scratch, parser stacks, and
output buffers.</p>
Its identity includes the source hash, compiler-image hash, target, ABI, and
representation version. Reusing an image after any of those change is an
error, not a cache hit.</p>
The binary format is deterministic and pointer-free. It uses little-endian
integers, a bounded string table, explicit tags, recursive pairs, and dense
vectors. The loader rejects unknown tags, truncated values, invalid intern
indexes, duplicate strings, excessive nesting, and trailing bytes.</p>
Publication is transactional enough for the bootstrap boundary: write a
temporary file, flush it, fsync</code> it, close it, and rename it over the final
path. A sidecar records the identity, size, and content hash. Every planning
and emission phase validates the manifest and image again.</p>
The result is not merely a cache. It is a lifetime boundary. Everything inside
the image is immutable and intentionally retained. Everything used to produce
it is eligible to die.</p>
The first bounded recovery implementation reclaimed memory by terminating a
worker process after a batch. It worked, but process exit was doing the job the
runtime should eventually understand.</p>
The new seed has resettable scratch arenas.</p>
One persistent measurement worker and one persistent emission worker load the
compiler environment and normalized image once. Each request creates an arena
checkpoint, performs one bounded unit of work, publishes only its stable
result, and resets to the checkpoint.</p>
immutable image and compiler environment</span></span>
                  |</span></span>
                  v</span></span>
          checkpoint scratch</span></span>
                  |</span></span>
                  v</span></span>
       measure or emit one function</span></span>
                  |</span></span>
                  v</span></span>
          publish stable result</span></span>
                  |</span></span>
                  v</span></span>
             reset scratch</span></span></code></pre>
The scratch arena reserves 512 MiB of virtual address space with
MAP_NORESERVE</code>; it does not make 512 MiB resident. Pages are committed on
demand. Reset discards whole scratch pages with madvise(MADV_DONTNEED)</code>,
restores counters and the used offset, and invalidates the checkpoint.</p>
Reset is also a safety operation. It fails if the checkpoint is stale, nested,
over capacity, or owns a resource that was opened after the mark and never
closed. The image serializer rejects any value whose address belongs to the
active scratch arena, including scratch children hidden inside a pair.</p>
That prevents a temporary value from quietly escaping into the supposedly
immutable compiler image.</p>
The full compiler currently has 910 functions. Recovery resets measurement
scratch once per function and emission scratch 911 times: once for each
function and once for the ABI note.</p>
Process isolation remains available as a diagnostic mode. It is no longer the
production reclamation mechanism.</p>
Lifetime fixes stop old work from accumulating. Representation fixes reduce
the cost of the state that really must remain alive.</p>
The seed's generic value cell used to occupy 56 bytes. It now occupies 24.
The common tag and two payload words are enough for integers, text and symbol
references, pairs, closures, builtins, and dense vectors. Function metadata
moved into a separate descriptor instead of inflating every value.</p>
That is a 57.14 percent reduction in cell allocator bytes.</p>
Repeated text and symbols are interned in deterministic first-use order. A
hash match still compares the complete bytes, so collisions cannot make two
different names alias. Textual token and node kinds become stable integer IDs.
Line and column values are packed into checked 16-bit fields. Indexed
top-level function forms use dense vectors instead of a cons cell for every
entry.</p>
The point was not to turn the language into a pile of clever bit tricks.</p>
The point was to spend rich tree structures where the compiler has trees, and
dense indexed structures where the compiler has tables.</p>
The next accidental lifetime was the artifact itself.</p>
A compiler that constructs an entire ELF image as hexadecimal text may hold
the AST, layout, machine bytes, hex encoding, concatenated output, and decoded
file representation at the same time. The final file may be small while the
path to it is extremely expensive.</p>
Seed recovery now uses a bounded 65,536-byte binary buffer. Exact writes retry
interruptions, advance after short writes, reject zero progress, and fail on
disk-full or invalid-path errors. Full buffers are flushed and reused.</p>
The recovery protocol is deliberately boring:</p>
write ELF header and startup</span></span>
for each canonical function:</span></span>
    emit one bounded chunk</span></span>
    append its bytes</span></span>
    reset emission scratch</span></span>
append ABI note</span></span>
verify exact planned file size</span></span>
chmod 0755</span></span></code></pre>
The partial file starts as mode 0600</code>. It becomes executable only after its
size matches the frozen plan and every append succeeds. chmod</code> is still the
small commit operation from the previous design; the difference is that the
bytes no longer travel through one giant retained text value.</p>
The compiler's current x86-64 function emitter still creates a hexadecimal
encoding internally. That value is bounded to one function and dies at the
next reset. Hex remains useful for diagnostics. It is no longer the artifact
transport.</p>
The normal native compiler needed the same treatment.</p>
A compiler pipeline has an obvious sequence:</p>
source -> tokens -> normalized forms -> validated forms</span></span>
       -> optimized forms -> layout -> machine code -> artifact</span></span></code></pre>
It is easy to implement that sequence while retaining every arrow's input and
output until process exit.</p>
0x0</code> now has an explicit retention graph. Raw source, tokens, validation
worklists, type and effect constraints, optimizer candidates, rendered OISA
records, and generated function chunks are phase-local. The normalized forms
and final native address table are the main compilation-lifetime structures.</p>
The frontend copies strings, symbols, and packed spans into normalized nodes,
then releases source and lexer storage. Validation keeps the validated module,
not its lookup tables and branch joins. Optimizer passes run in scratch and
copy only the accepted form graph into persistent storage. Layout retains
names, sizes, and addresses. Emission writes one function and resets.</p>
Diagnostics still keep line and column information because normalized nodes
own compact spans. Releasing the parser does not mean releasing the ability to
explain an error.</p>
Compiler dumps became observations rather than phases. Optimizer variants run
sequentially. Each process constructs one requested representation, streams
it, records a compact comparison summary, and exits before the next variant.
There is no in-process list containing O0, every intermediate pass, O1, SSA,
LIR, and disassembly at once.</p>
The historical interpreter multi-dump peak was 7,852,696 KiB. The accepted
sequential native optimizer lane measured 90,916 KiB. That is not one magical
allocator optimization; it is the result of changing execution, retention,
and serialization together.</p>
Normal native and OISA compiler output is streamed too. Writers maintain an
online byte count and FNV-1a-64 digest while writing, so callers can validate
the result without retaining or rereading a complete output value.</p>
Three compiler generations now reproduce the same artifact at:</p>
Generation</th> Peak RSS</th> Parity</th></tr></thead>

1</td> 77,984 KiB</td> trusted parent, byte-identical</td></tr>
2</td> 70,232 KiB</td> generation 1, byte-identical</td></tr>
3</td> 77,984 KiB</td> generation 2, byte-identical</td></tr>
</tbody></table>
That is the ordinary self-host path, not the expensive assembly-seed recovery
path.</p>
Compiler memory was only half of the roadmap.</p>
I only care about 0x0</code> as a Linux application platform right now. For that
target, process-lifetime allocation is not enough. A server cannot call
mmap</code>, forget every result, and claim success because the kernel cleans up
when the process eventually dies.</p>
The direct ELF backend now implements a managed native profile with:</p>

unique ownership and moves;</li>
lexical drops;</li>
bounded regions with escape checks;</li>
precise non-atomic reference counting for shared acyclic values;</li>
request and task arena resets;</li>
destructors for files, sockets, and supervised child processes.</li>
</ul>
This code is emitted directly into the Linux x86-64 executable. It does not
call C, Python, a tracing collector, or a hidden helper runtime.</p>
A unique value has one owner. Moving it transfers that ownership. The compiler
inserts terminal drops in reverse lexical order and rejects double drops,
use-after-move, and ownership-class mismatches.</p>
A region owns a bounded collection of allocations. Releasing the region
releases the collection together. Returning a value whose region ends at that
return is rejected before native layout. Cleanup is emitted on normal exits
and panic paths.</p>
A genuinely shared value uses precise strong reference counting. Retains make
aliases; releases destroy the value when the count reaches zero. The current
profile is single-threaded, so these counters are intentionally non-atomic.
Shared graphs are immutable and acyclic. Explicit cycles are rejected; cyclic
working state belongs in a bounded region.</p>
Each unique, shared, or region owner receives a 16 MiB demand-mapped address
range. Again, virtual capacity is not resident memory. Only touched pages
consume RSS. Text and list allocations made under that owner use the range,
and the terminal drop or reset reclaims the complete composite with
munmap(2)</code>.</p>
Generation-checked owner slots catch stale handles even when an alias crosses
a function boundary.</p>
Memory safety is not complete if the heap returns to zero while the process
leaks a socket on every request.</p>
Files, sockets, and supervised child processes are ownership-bearing native
values. File and socket destruction calls close(2)</code>. Child destruction sends
SIGKILL</code> and waits with wait4(2)</code>, preventing zombies and orphans. Resources
registered inside an owner are destroyed before its mapping is released.</p>
The runtime publishes logical counters for live slots, live bytes, regions,
shared values, resources, drops, request resets, task resets, mapped spans,
and mapped bytes.</p>
RSS is useful evidence. It is not the only evidence.</p>
A flat RSS curve can hide a logical leak inside an allocator that reuses
pages. Zero logical counters can hide an allocator that never gives pages back
to the kernel. The release gate requires both the ownership counters and the
resident-memory plateau.</p>
It also includes negative controls. One test deliberately suppresses inferred
cleanup. The leak detector must catch that program. A leak suite that cannot
detect an intentional leak has only proved that its happy path is quiet.</p>
Fast loops catch obvious imbalance. They do not catch every periodic cleanup
bug, counter wrap, child-process leak, or slow RSS staircase.</p>
The final release operation therefore had an inconvenient acceptance test:</p>
MEMOPT_RELEASE_SOAK</span>=</span>1</span> \</span></span>
MEMOPT_LEAK_ITERATIONS=1000000</span> \</span></span>
MEMOPT_SOAK_SECONDS=86400</span> \</span></span>
make</span> native-memory-soak-check</span></span></code></pre>
The accepted run recorded:</p>
Measurement</th> Result</th></tr></thead>

Duration</td> 86,400 seconds</td></tr>
Configured leak iterations</td> 1,000,000</td></tr>
Soak batches</td> 577,424</td></tr>
Iterations per soak child</td> 16</td></tr>
Warm peak RSS</td> 10,104 KiB</td></tr>
Final peak RSS</td> 10,380 KiB</td></tr>
Live allocations</td> 0</td></tr>
Live resources</td> 0</td></tr>
Mapped spans</td> 0</td></tr>
</tbody></table>
The runner writes accepted evidence only after the full duration. An
interrupted or failed run publishes nothing. The evidence records the compiler
and fixture hashes, so changing the compiler invalidates the result.</p>
A one-second test cannot be renamed into a release soak. A fixture cannot
stand in for wall-clock evidence. The final cross-domain validator fails closed
if the durable run is missing, too short, stale, or attached to another
compiler revision.</p>
After the run returned native memory soak check ok</code>, the release decision
could finally change to pass</code>.</p>
The seed-recovery progression now looks like this:</p>
Recovery design</th> Peak RSS</th></tr></thead>

Monolithic seed ELF builder</td> 12,667,784 KiB</td></tr>
Bounded process workers</td> 3,345,556 KiB</td></tr>
Image + arenas + compact values + binary output</td> 344,860 KiB</td></tr>
</tbody></table>
The final full recoveries were:</p>
Artifact</th> Peak RSS</th> Limit</th> Parity</th></tr></thead>

ELF compiler builder</td> 343,524 KiB</td> 524,288 KiB</td> stage 2/stage 3 identical</td></tr>
ELF OISA compiler</td> 343,344 KiB</td> 524,288 KiB</td> trusted OISA identical</td></tr>
Builder ratchet rerun</td> 344,860 KiB</td> 524,288 KiB</td> seed builder identical</td></tr>
</tbody></table>
The 512 MiB release ceiling leaves room above the measured host without
pretending every machine has identical RSS behavior.</p>
More importantly, the explanation changed.</p>
The old answer was, "the seed VM retains a lot, so give it four GiB."</p>
The new answer names the retained image, scratch arenas, value layout, output
buffer, compiler phase graph, native owners, resource destructors, and release
evidence. Each has an owner, a boundary, and a gate.</p>
What This Does Not Claim🔗</a></h2>
The current production statement is intentionally narrow:</p>

0x0</code> has a bounded memory and lifetime profile for direct ELF Linux x86-64
programs using Unit, Bool, I64, Text, and List values.</p>
</blockquote>
I started this work because 3.2 GiB felt like an embarrassing footnote on a
successful self-host.</p>
The result is better: memory is no longer an unnamed pile owned by the
process. The compiler knows which state must persist. Workers know what can be
reset. Native values know who drops them. Resources have destructors. The
release knows what was measured.</p>
And after twenty-four hours, everything that was supposed to be dead was still
dead.</p>


0x0 Self-Hosting Without The C Detour
2026-07-17T00:00:00+00:00
Which compiler built the compiler? What built that compiler? Which artifact is
trusted? What happens if the trusted binary disappears? Does recovery go
through another language? Does the process finish on a machine I can actually
afford?</p>
It is easy to say a compiler compiles itself after one successful demo. It is
harder to make the claim precise enough that a clean checkout can prove it.</p>
That is what changed in 0x0</code>.</p>
After writing about 0x0 technically</a>, its
ABI and ELF boundary</a>, and its
distribution model</a>, I ended up back at the least
glamorous part of language design: deleting old scaffolding, drawing a stricter
trust boundary, and watching a compiler use twelve gigabytes of memory to
produce a file smaller than one megabyte.</p>
The work is recorded in ADR-0188 through ADR-0191. Together they changed the
answer to a useful question:</p>

Can 0x0</code> recover and reproduce its native compiler without generating C?</p>
</blockquote>
The answer is now yes.</p>
The answer also comes with footnotes, because trustworthy bootstrapping is
mostly footnotes with executable tests.</p>
The first change was not a compiler feature. It was deleting
python-dehosting-roadmap.md</code>.</p>
That file planned the migration of the repository's Python tooling into 0x0</code>.
It was useful while the migration was moving. At closure, the live ledger
reported 176 migrated rows, with zero remaining rows, zero host-only rows, and
zero temporary shim rows.</p>
Keeping the roadmap after that point would not preserve useful history. It
would create a second, stale place where somebody could try to record current
state.</p>
The active truth now lives in things that can fail:</p>

the migration progress ledger;</li>
the no-Python exceptions ledger;</li>
the Python de-hosting progress gate;</li>
the no-Python repository gate;</li>
release checks and ADRs.</li>
</ul>
There is still an explicit exceptions ledger for residual non-source helpers
that need native JSON, time, or rewrite replacements. That is not hidden behind
a completed percentage. It is a named caveat with a gate around it.</p>
I like this distinction more than I expected. A roadmap says what I intended
to do. A ledger and a gate say what the checkout can prove now.</p>
ADR-0188 retired the intention document after the proof replaced it.</p>
Before these changes, the full self-host target could pass through a native
helper built like this:</p>
compiler/compat-main.0x0</span></span>
        |</span></span>
        v</span></span>
stage 2 OISA compiler</span></span>
        |</span></span>
        v</span></span>
build/native/zero-native.c</span></span>
        |</span></span>
        v</span></span>
host C compiler</span></span>
        |</span></span>
        v</span></span>
bin/zero-native</span></span></code></pre>
There is nothing fake about generating C. It is a useful backend and an
excellent compatibility oracle. C gives a young language access to mature
optimizers, system headers, linkers, and decades of platform knowledge.</p>
But it proves a different statement.</p>
It proves that 0x0</code> can translate its compiler through C and that a host C
toolchain can finish the job. It does not prove that the native 0x0</code> compiler
path can recover itself without that detour.</p>
I did not want make full-selfhost</code> to quietly answer the easier question.</p>
ADR-0189 moved the normal gate to the native ELF compiler builder:</p>
trusted zero-elf-compiler</span></span>
        |</span></span>
        v</span></span>
zero-elf-compiler</span></span>
        |</span></span>
        v</span></span>
zero-elf-stage2</span></span>
        |</span></span>
        v</span></span>
zero-elf-stage3</span></span>
</span>
zero-elf-stage2 == zero-elf-stage3</span></span></code></pre>
The comparison is byte-for-byte. Stage 2 must compile the compiler into stage
3 without changing it.</p>
The C route still exists, but now its names tell the truth:</p>
make</span> c-compat-native</span></span>
make</span> c-compat-full-selfhost</span></span>
make</span> native-compat-check</span></span></code></pre>
Compatibility is useful. Compatibility is not the trusted root.</p>
Removing C from the normal gate exposed the next question.</p>
What if the trusted release compiler is missing?</p>
A self-hosted compiler cannot appear from its own source. There is always a
first executable somewhere: an older compiler, an interpreter, a tiny seed, or
another language implementation.</p>
0x0</code> keeps a small x86-64 assembly seed. Its OISA succession looks like this:</p>
seed/zero.s</span></span>
    |</span></span>
    v</span></span>
stage1.oisa</span></span>
    |</span></span>
    v</span></span>
stage2.oisa</span></span>
    |</span></span>
    v</span></span>
stage3.oisa</span></span>
</span>
stage2.oisa == stage3.oisa</span></span></code></pre>
OISA is the intermediate instruction set used by the self-host chain. The
assembly seed can produce stage 1. Stage 1 compiles the compiler into stage 2.
Stage 2 compiles it into stage 3. If stages 2 and 3 differ, the succession is
not stable and the bootstrap stops.</p>
The remaining hole was turning that stable stage2.oisa</code> image into the native
ELF compiler artifacts without asking the compatibility backend to emit C.</p>
ADR-0190 added direct seed commands for two executables:</p>

an ELF OISA compiler, which compiles compiler/main.0x0</code> back to the expected
stage 2 OISA image;</li>
an ELF compiler builder, which emits another native ELF compiler builder and
can reproduce itself byte-for-byte.</li>
</ul>
That gives the recovery chain another branch:</p>
seed/zero.s</span></span>
    |</span></span>
    v</span></span>
stable stage2.oisa</span></span>
    |</span></span>
    +----> native zero-oisa-compiler ----> expected stage2.oisa</span></span>
    |</span></span>
    +----> native zero-elf-compiler</span></span>
                    |</span></span>
                    v</span></span>
              zero-elf-stage2</span></span>
                    |</span></span>
                    v</span></span>
              zero-elf-stage3</span></span>
</span>
              stage2 == stage3</span></span></code></pre>
No C source is generated in that branch. No C program is compiled. The seed
path writes the ELF compiler artifacts directly.</p>
This does not mean 0x0</code> materializes from nothing. The first trusted boundary
still includes the assembly seed and the host machinery needed to assemble and
run it. The current native target is Linux x86-64. The operating system, CPU,
assembler, linker, and source checkout remain part of the bootstrap story.</p>
The first direct seed implementation worked.</p>
It was also a small memory disaster.</p>
The monolithic compiler-elf-builder-stage2</code> command loaded the stage 2 image,
parsed the compiler, planned the ELF layout, generated every function, and
held parser, layout, and code-generation temporaries until the process exited.
On the measured compiler source, it peaked at:</p>
12,667,784 KiB RSS</span></span></code></pre>
The output executable was around 672 kilobytes.</p>
Chunking only the final text did not help. The problem was not the size of the
hex string written to disk. The seed VM retained all the intermediate
allocations that had produced it.</p>
This is the kind of bug that makes a feature technically complete and
operationally imaginary. A recovery path that needs an undocumented 16 GiB
allowance is not a comfortable first root.</p>
ADR-0191 changed the unit of work.</p>
Direct ELF generation has a slightly annoying dependency. A function body may
contain an absolute call to another function. To encode that call, the emitter
needs the callee's address. To know that address, it needs to know the sizes of
all functions before it.</p>
So the compiler cannot safely emit arbitrary functions and discover the
layout afterward.</p>
The solution was to separate planning from emission:</p>
normalize and index function order</span></span>
                |</span></span>
                v</span></span>
measure function sizes in bounded batches</span></span>
                |</span></span>
                v</span></span>
freeze names, addresses, entry point, file size,</span></span>
ELF header/start bytes, and ABI note in a plan</span></span>
                |</span></span>
                v</span></span>
emit function chunks in bounded batches</span></span>
against the frozen address table</span></span>
                |</span></span>
                v</span></span>
append ABI note</span></span>
                |</span></span>
                v</span></span>
verify exact planned size</span></span>
                |</span></span>
                v</span></span>
chmod executable</span></span></code></pre>
The default batch contains 32 functions. Each worker loads the stable stage 2
compiler state, handles its bounded slice, writes its result, and exits. Exit
is important: it gives the operating system a chance to reclaim everything the
seed VM does not reclaim during a long process.</p>
The first pass measures function sizes. Those measurements produce a raw
address table. The plan finalizer then computes the artifact-specific startup
stub, entry point, function base, exact file size, and ABI note.</p>
The second pass emits real function bytes using the frozen addresses. The OISA
compiler and the compiler builder share function measurement and body
emission, while keeping separate startup and plan identities.</p>
This makes every emitted call agree with the same layout without keeping every
function's temporary state alive at the same time.</p>
It is slower. Stage 2 loading and normalization repeat across workers. That is
an acceptable trade for a recovery and audit path. I would rather wait for a
bounded process than discover that the bootstrap proof only works on one large
machine.</p>
There is another detail in the new flow that I like.</p>
The output file is not executable while it is being assembled.</p>
The driver writes the header and startup bytes, appends every decoded function
chunk, appends the ABI note, and compares the actual file size with the frozen
plan. Only after all those checks pass does it apply executable permissions.</p>
That turns chmod</code> into a tiny commit operation.</p>
A killed worker may leave a partial file, but it does not leave a partial file
pretending to be a compiler. The filesystem metadata communicates whether the
transaction completed.</p>
This is not a replacement for atomic rename or signed release artifacts. It is
still a useful local invariant: incomplete compiler bytes should not look
runnable.</p>
The long bounded run found a bug outside the compiler.</p>
The RSS limiter samples the worker process group while the build runs. Over a
long self-host, the shell created tens of thousands of short-lived sampler
children. One valid build finished and produced the correct artifact, but the
wrapper surfaced shell wait</code> status 127</code> instead of the command's real
status.</p>
The compiler had succeeded. The evidence wrapper had lied about it.</p>
The fix was to let the monitored command record its own exit status inside the
process group before the leader exits, with wait</code> retained as a fallback. The
full target was then rerun through the limiter.</p>
This is a useful bootstrap lesson. A proof is only as reliable as the program
collecting the proof. Build wrappers, timeout handlers, memory samplers, and
comparison commands are part of the trust story too.</p>
The original 729-function builder measurement dropped from 12,667,784 KiB to
3,154,848 KiB peak RSS.</p>
The current 736-function compiler completed with these results:</p>
Artifact</th> Peak RSS</th> Output size</th> Parity result</th></tr></thead>

ELF compiler builder</td> 3,345,556 KiB</td> 672,106 bytes</td> self-reproduced byte-for-byte</td></tr>
ELF OISA compiler</td> 3,337,388 KiB</td> 672,023 bytes</td> emitted the trusted stage 2 image byte-for-byte</td></tr>
</tbody></table>
Both ran below the enforced 4 GiB ceiling. Both returned status zero through
the fixed process-group limiter. Neither generated C.</p>
The result is not tiny. Three-point-two GiB is still a serious recovery budget
for a 672 KiB artifact. The important change is that the budget is now bounded,
measured, enforced, and low enough for an ordinary development machine.</p>
There is more memory work to do. There is no reason to turn a successful bound
into a permanent excuse.</p>
The project now has three deliberately different paths.</p>
make full-selfhost</code> prefers the trusted release compiler. It builds a native
ELF compiler builder, uses that builder to produce stage 2, uses stage 2 to
produce stage 3, and compares the two executables byte-for-byte.</p>
If the trusted release compiler is absent, the target can recover the native
builder from the seed-produced stage 2 OISA image through the bounded driver.</p>
make bootstrap-from-seed</code> explicitly starts from the assembly seed, proves
OISA stage 2/stage 3 equality, emits both native compiler artifacts through the
bounded seed path, and proves the native compiler builder can reproduce itself.</p>
This is the expensive path on purpose. It exists to recover or audit the
trusted release root, not to make every edit pay the full bootstrap cost.</p>
The generated-C and GAS-backed paths remain available behind explicit
c-compat-*</code> and native-compat-check</code> targets. They are useful for comparison,
platform experiments, and catching backend disagreement.</p>
They no longer silently define what "full self-host" means.</p>
0x0</code> can compile its compiler into a native executable, run that compiler like
another program, and reproduce it without generating C.</p>
Glossary</strong></p>
Self-hosting: a compiler written in the language it compiles.</p>
Bootstrap: the process that creates the first usable compiler artifact from a
smaller trusted root.</p>
Trusted root: the starting artifact or implementation accepted as the basis of
the compiler succession proof.</p>
Seed: the small assembly implementation used to start the 0x0</code> compiler
chain.</p>
OISA: the intermediate instruction set used by the 0x0</code> self-host chain.</p>
ELF: Executable and Linkable Format, the native executable format emitted by
the current Linux x86-64 backend.</p>
RSS: Resident Set Size, an approximation of the physical memory held by a
process.</p>
Parity: byte-for-byte agreement between two independently produced stages or
artifacts.</p>
ABI note: the marker appended to a direct ELF artifact to identify the binary
contract it claims to implement.</p>


0x0 Distribution
2026-07-12T00:00:00+00:00
I'm learning that adding a network to a programming language is easy if I lie
to myself, just a bit.</p>
I can call a socket, serialize a value, send some bytes, and say the language
is distributed. The demo works. Two terminals print something. I am genius
for a few seconds.</p>
Then one node disappears after receiving a message but before acknowledging
it. The sender does not know whether to retry. The retry may perform the work
twice. A worker crashes, restarts, and finds an old message. Two nodes disagree
about membership. A token leaks into a diagnostic report. The network delivers
message 2</code> before message 1</code>.</p>
The socket was the easy part.</p>
The real distributed system begins when the answer to "what happened?" is
"we cannot know from here."</p>
That is the problem 0x0</code> is starting to tackle.</p>
This follows my earlier attempt to describe 0x0 technically</a>.
The short version is that 0x0</code> is a small, symbolic, pure-functional language
kernel with a self-hosted compiler. It looks like a Lisp, emits native
artifacts, and has an unhealthy interest in making its contracts inspectable.</p>
That last part turns out to be useful when the network gets involved.</p>
A Remote Call Is Not A Function Call</strong></p>
A local function call has a fairly comfortable contract. Control enters a
function and eventually returns, panics, or kills the process. The caller and
callee share one machine's memory and failure boundary.</p>
A remote operation adds uncomfortable states:</p>

the message was never sent;</li>
the message was sent but never received;</li>
the message was received but not processed;</li>
the message was processed but not acknowledged;</li>
the acknowledgement was sent but not received;</li>
the operation ran twice;</li>
the recipient restarted and forgot what it knew;</li>
the sender and recipient disagree about who belongs to the cluster.</li>
</ul>
This is why I do not want remote execution to look exactly like an ordinary
function call. Hiding those states does not remove them. It only makes the
failure policy accidental.</p>
0x0</code> starts from actors and messages instead.</p>
(ƒ send-job</span></span>
  (∷ (→ (RemoteActor Text) Text Any))</span></span>
  (↯ actor)</span></span>
  (worker payload)</span></span>
  (⟿ worker payload))</span></span></code></pre>
The RemoteActor</code> type carries intent. The actor</code> effect says this function
crosses the actor runtime boundary. The ⟿</code> form says this is a remote send.</p>
There is an important limitation: this source form does not open a network
connection by itself. The compiler lowers it to an ordinary tagged value:</p>
(list "RemoteActorSend" worker payload)</span></span></code></pre>
That value is a descriptor. It says what the program wants the runtime to do.
The runtime remains responsible for scheduling, transport, delivery, and
failure policy.</p>
I like this separation. Syntax records intent. Data carries the intent across
the boundary. Effects prevent pure code from secretly performing the action.</p>
The Actor-Shaped Core</strong></p>
The actor model gives each unit of work an identity and a mailbox. Instead of
sharing mutable state directly, actors exchange messages. In the model used by
0x0</code>, an actor has:</p>

an actor reference containing a node, name, and message type;</li>
a FIFO mailbox;</li>
a processed-message log;</li>
a restart count;</li>
an alive or dead state.</li>
</ul>
Messages have a sender, recipient, payload, and type. The local model uses a
deterministic scheduler: actor names have a stable order and one message is
dequeued per step.</p>
It creates useful failure boundaries. A worker can fail without making every
actor share its stack and mutable state. A mailbox gives pending work an
explicit home. An actor reference separates logical identity from a raw
pointer or socket.</p>
The repository also defines pure constructors for the runtime vocabulary:</p>
(actor-ref node name)</span></span>
(actor-mailbox owner messages)</span></span>
(actor-typed-send sender recipient payload)</span></span>
(actor-dead-letter sender recipient payload)</span></span>
</span>
(actor-supervision-policy strategy max-restarts window)</span></span>
(actor-crash-report actor failure fingerprint)</span></span>
(actor-restart-limit policy count window)</span></span></code></pre>
They produce values such as:</p>
(list "ActorSupervisionPolicy" strategy max-restarts window)</span></span></code></pre>
A policy can be inspected, serialized, hashed, tested, or rejected before a
host runtime acts on it.</p>
Fault Tolerance Means Deciding How To Fail</strong></p>
A failure has a bounded effect and a defined next decision.</p>
0x0</code> breaks that decision into a few explicit pieces.</p>
Supervision</strong></p>
A supervisor owns a restart strategy, a maximum restart count, and a time
window. A crash becomes a typed report. The next action becomes a supervision
decision: restart, stop, or escalate.</p>
The useful part is the restart budget. It is a denial-of-service loop with
optimistic branding. A bounded restart policy makes the failure visible when
recovery is no longer working.</p>
The local fixture models a worker receiving one</code>, boom</code>, and two</code>. boom</code>
causes a crash; the supervisor restarts the worker if its budget allows it; the
event report records the crash and restart.</p>
Dead Letters And Acknowledgements</strong></p>
An undeliverable message is not discarded as an invisible transport detail. It
can become an ActorDeadLetter</code> or DistributedDeadLetterReport</code>. Successful
delivery has a DistributedDeliveryAck</code> descriptor.</p>
An acknowledgement still does not prove that business work happened exactly
once. It only proves whatever layer the acknowledgement contract defines. That
distinction matters. Distributed systems get dangerous when "received,"
"processed," and "committed" are treated as synonyms.</p>
Replay</strong></p>
Actor events have a sequence and a replay fingerprint. The goal is to make a
failure reproducible from the event stream.</p>
Determinism helps here. If scheduling order is stable, replay and bounded model
checking have fewer meaningless interleavings to explore. The repository has
contracts for replay events, fingerprints, distributed replay plans, and
counterexample reports.</p>
The current replay gate is deliberately small. It validates fixture
fingerprints and rejects known tampering cases; it is not yet a durable,
cryptographically chained event log. The shape exists before the full storage
system does.</p>
Capability Boundaries</strong></p>
0x0</code> separates source effects from detailed runtime capabilities such as:</p>
cap.actor.runtime</span></span>
cap.replay.deterministic</span></span>
cap.distributed.node</span></span>
cap.network.client</span></span>
cap.network.server</span></span></code></pre>
Cluster membership also carries capability advertisements. A node should not
receive work it is not allowed or able to perform. The cluster contract names
rejection cases for invalid credentials, sender spoofing, replayed nonces, and
capability mismatch.</p>
This is fault tolerance too. Rejecting an invalid transition before it mutates
state is usually cheaper than recovering afterward.</p>
Distribution As Layers</strong></p>
The current design is easier to understand as layers:</p>
0x0 actor syntax</span></span>
        |</span></span>
        v</span></span>
tagged intent values</span></span>
        |</span></span>
        v</span></span>
deterministic actor and supervision model</span></span>
        |</span></span>
        v</span></span>
host transport boundary</span></span>
        |</span></span>
        v</span></span>
event, replay, and release evidence</span></span></code></pre>
At the source level, actor</code>, remote-actor</code>, !</code>, ⟿</code>, receive</code>, and select</code>
become tagged data.</p>
At the runtime-contract level, runtime/distributed-actors.0x0</code> defines nodes,
envelopes, partitions, membership, authentication, acknowledgements, dead
letters, reconnect plans, supervision, and replay.</p>
At the local behavior level, the actor gate checks fixture reports for FIFO
mailboxes, crashes, restart policy, duplicates, out-of-order messages,
partitions, unauthorized sends, and counterexamples.</p>
At the transport level, the distributed-cluster gate opens one-shot loopback
TCP listeners, probes three named nodes, records their addresses and capability
advertisements, and verifies the report and replay contract.</p>
What The Current Gate Actually Proves</strong></p>
The repository documentation carefully calls this a bounded loopback boundary.
Looking at the implementation makes the boundary even clearer.</p>
The cluster adapter really opens local TCP listeners and exchanges status JSON
over 127.0.0.1</code>. That proves the host environment can create and reach the
transport endpoints used by the gate.</p>
The current adapter also writes deterministic fixture evidence for delivery
acknowledgements, duplicates, dead letters, supervised restarts, partitions,
timeouts, reconnects, unauthorized tokens, spoofing, nonce replay, and
capability mismatches. The tests verify that those report fields and stable
diagnostics remain present, and that raw credentials do not appear in the
report.</p>
What it does not yet do is drive every one of those failure cases through a
long-lived concurrent message transport. The actor adapter is also a fixed
deterministic fixture, not yet a general scheduler for arbitrary application
actors.</p>
So:</p>

0x0</code> has source forms and pure contracts for actor and distributed intent;</li>
it has deterministic supervision, failure, replay, and model-check evidence
shapes;</li>
it has a real local TCP probe boundary and stable report gates;</li>
it does not yet have a production remote cluster runtime.</li>
</ul>
There are no durable distributed mailboxes, WAN partition claims,
cross-version protocol negotiation, managed membership service, or remote
datacenter deployment here yet.</p>
A contract scaffold is valuable when it is presented as a
contract scaffold. It gives the next implementation something precise to
replace and something stable to preserve.</p>
Why The Lisp-Like Syntax Helps</strong></p>
The parentheses are not what make a system distributed. They do make the
language unusually convenient for describing one.</p>
The Syntax Is Already A Tree</strong></p>
This:</p>
(⟿ worker "compile")</span></span></code></pre>
is already close to its abstract syntax tree. The compiler does not need to
recover a complicated structure from many unrelated grammar rules. It sees a
list whose head is ⟿</code> and whose remaining elements are arguments.</p>
The lowering is correspondingly boring:</p>
(list "RemoteActorSend" worker "compile")</span></span></code></pre>
Boring lowering is good. There are fewer places for source intent to disappear
between parser, checker, compiler, runtime, and replay tooling.</p>
Code And Protocol Data Share A Shape</strong></p>
Actor messages, supervision policies, replay events, and cluster descriptors
are tagged lists. Source code is also made of symbolic list forms.</p>
I would call this homoiconic in spirit. The useful property today is simpler:
the source tree and the runtime contract tree resemble each other.</p>
That resemblance makes small domain-specific forms cheap to add. receive</code> and
select</code> do not require inventing an entirely separate mini-language. They are
new symbolic heads with checked argument shapes and explicit lowerings.</p>
Effects Stay Visible</strong></p>
The function shape puts its contract next to its implementation:</p>
(ƒ handle-message</span></span>
  (∷ (→ (Actor Text) Text Any))</span></span>
  (↯ actor)</span></span>
  (worker message)</span></span>
  (! worker message))</span></span></code></pre>
The type says what values cross the boundary. The effect row says what kind of
world the function may touch. The body says what it does. All three are forms
in the same tree and can be inspected before code generation.</p>
For a distributed language, that is more than visual consistency. It lets the
compiler reject pure code that attempts an actor or network effect. The syntax
makes authority reviewable.</p>
Small Syntax Supports Multiple Interpreters</strong></p>
0x0</code> has a self-hosted compiler, an assembly recovery seed, native backends,
runtime tooling, and evidence checkers. A uniform s-expression surface reduces
how many different parsers and representations those paths need to agree on.</p>
When the project is trying to verify compiler succession, ABI rules, runtime
capabilities, and replay contracts, a small grammar is not minimalism for its
own sake. It is a way to reduce the trusted surface.</p>
The tradeoff is real. Unicode symbols such as ƒ</code>, ∷</code>, ↯</code>, and ⟿</code> are compact
and visually distinct, but they are harder to type, search for, and explain to
tools that assume ASCII. Parentheses also make malformed nesting easy for a
human to miss without editor support.</p>
I still think the structural win is worth exploring. The syntax makes policy
look like data, and distributed systems are mostly policy wearing a network
cable.</p>
The Lesson</strong></p>
The interesting part of distribution in 0x0</code> is not that it can open a local
socket. Almost every general-purpose language can do that.</p>
The interesting part is the attempt to make the uncomfortable decisions
explicit:</p>

who owns a mailbox;</li>
what identifies a node and an actor;</li>
what a message is allowed to contain;</li>
which effects a function may perform;</li>
what happens when a worker crashes;</li>
how often it may restart;</li>
where an undeliverable message goes;</li>
what an acknowledgement means;</li>
which event order is replayed;</li>
what a gate actually proves.</li>
</ul>
The Lisp-like syntax helps because every one of those decisions can become a
small symbolic form, a tagged value, or a checked policy. The fault-tolerance
story helps because every failure can become an event and a bounded next
decision instead of an invisible exception somewhere behind a remote call.</p>
Glossary</strong></p>
Actor: an isolated unit of computation with an identity and a mailbox.</p>
Mailbox: the queue of messages waiting for an actor.</p>
Supervision: a policy for deciding whether a failed actor should restart,
stop, or escalate its failure.</p>
Dead letter: a message that could not be delivered to its intended recipient.</p>
Replay: reproducing or validating behavior from a recorded event sequence.</p>
Capability: explicit authority to perform an effect such as actor execution,
network access, or file access.</p>
Partition: a condition where nodes cannot communicate even though one or both
may still be running.</p>
S-expression: a parenthesized symbolic list used to represent code or data.</p>
Homoiconicity: the property of a language whose code has the same basic
representation as its data. 0x0</code> currently benefits from this resemblance
without claiming a complete Lisp macro environment.</p>


ABI 0x0
2026-07-04T00:00:00+00:00
I'm learning a lot designing my own programming language, 0x0.
Some terms I'm recalling from my days of compiling linux.
But most, I'm totally lost. Here's my journey with ABI's Ox0.</p>
Wine can run a Windows program on Linux. On x86-64, that does
not mean every instruction is being interpreted by an emulator.
Windows code and Linux code can exist in the same process,
in the same virtual address space.</p>
The magic ends when one side tries to call the other.</p>
At that point the CPU does not care about "Windows function" or "Linux
function". It cares about registers, stack layout, memory addresses, return
values, symbol tables, object formats, and ownership rules. That pile of
promises is the ABI: the Application Binary Interface.</p>
An API says:</p>
read_proc_version</span>(</span>args</span>)</span></span></code></pre>
An ABI says:</p>

which register contains args</code>;</li>
which register contains the return value;</li>
whether the caller or callee cleans anything up;</li>
how the stack must be aligned;</li>
what object file symbol exposes the function;</li>
what the pointed-to memory looks like;</li>
who owns that memory after the call returns;</li>
what counts as success or failure.</li>
</ul>
That is why ABI work is writing a border treaty between two runtimes.</p>
The fun part is that this is also a useful way to understand what 0x0</code>
is doing with ELF output. 0x0</code> is not just "emitting a binary".
It is deciding what binary promises exist, how to stamp them into
artifacts, and how to reject artifacts that do not keep those promises.</p>
The Wine: Same Process, Different Contracts</strong></p>
ArcaneNibble's post, "How to call Linux code from a Wine process"</a>,
is a great real-world ABI tour because it starts from a weird but practical
question: if Wine has Windows and Linux code in one process, can a
Windows-side program call Linux-side code?</p>
The answer is "yes", but every version of "yes" is really an ABI story.</p>
One route is the raw, low-level route. If Linux shared libraries are already
mapped into the process, you can go hunting through loaded ELF metadata.
The post walks through finding the loaded libc image, finding PT_DYNAMIC</code>,
reading dynamic table entries such as DT_SYMTAB</code>, DT_STRTAB</code>,
and DT_GNU_HASH</code>, then manually locating dlsym</code>.</p>
That is already a good ELF lesson: section headers are mostly a
link-time and tooling convenience. The runtime loader cares about program
headers and dynamic metadata. When inspecting a loaded image, file
offsets are not the main thing anymore. Virtual addresses are.</p>
But finding the function address is not enough. The post has to call
the Linuxfunction with the System V x86-64 calling convention, even
though the caller is still a Windows program. A function pointer value
by itself is just an address. The ABI tells you how to enter that
address without corrupting the conversation.</p>
That matters on x86-64 because Windows and System V use different
calling conventions. The first few integer or pointer arguments
live in different registers, stack rules differ, and a compiler needs
to know which contract it is targeting. In Rust terms, this is the
difference between tagging a function as something like
extern "system"</code> for the Windows side and extern "sysv64"</code> for
the Linux side.</p>
The cleaner route in the article is Wine's unixlib</code> mechanism.
Instead of freely mixing Windows and Linux code inside one module,
Wine pairs a PE DLL with a normal native ELF .so</code>. The PE side
asks Wine for a handle to the native side, then calls
__wine_unix_call_dispatcher</code> with:</p>

a unixlib handle;</li>
a numeric function index;</li>
one pointer-sized argument.</li>
</ul>
The ELF side exports a known data symbol, __wine_unix_call_funcs</code>,
which is an array of function pointers. Each function has the same
simple shape: one pointer argument, one 32-bit status result.
Complex arguments get packed behind the pointer.</p>
This is the part I like most: unixlib makes the ABI bridge boring
on purpose. The dispatcher can bridge between the Windows ABI
and the System V ABI because the callable surface has been reduced
to one uniform function shape.</p>
That is a general systems trick. When the boundary is dangerous,
make the shape of the boundary small.</p>
ELF, the Container</strong></p>
ELF is the file format in the middle of this story. It can
describe executable images, relocatable object files, shared
objects, symbols, relocation records, loadable segments,
interpreter paths, dynamic linking data, notes, and more.</p>
An ELF file can say:</p>

"I am ELF64";</li>
"I target x86-64";</li>
"load this segment at this virtual address";</li>
"this is a relocation against this symbol";</li>
"this dynamic table points to these runtime structures".</li>
</ul>
It does not, by itself, tell you that a language's Text</code>
value is a NUL-terminated UTF-8 pointer. It does not tell
you that a return value is split between a payload register
and a tag register. It does not tell you whether an object
file is safe to link with another object file from the
same language.</p>
Those are ABI choices layered on top of the object format.</p>
Wine's unixlib works because it uses ELF for the Linux side,
PE for the Windows side, and a deliberately tiny ABI bridge
between them. 0x0</code> is interesting for the same reason: it
treats ELF as the serialization format, then defines a small
language ABI on top of it.</p>
What 0x0 Actually Manages</strong></p>
0x0</code> is a symbolic, Lisp-like, pure-functional language kernel
with a self-hosted compiler chain. The repository has several
native artifact paths:</p>

direct ELF64/x86-64 executables;</li>
ELF64 relocatable objects;</li>
archives;</li>
linked executables;</li>
compatibility C and GAS paths used for comparison and recovery.</li>
</ul>
The important thing is that the ABI is not left as an implied
property of the current compiler. The repository writes it down
and checks it.</p>
The ABI guide says ABI version 0.1</code> is Linux x86-64 only. It
uses ELF64, little-endian encoding, and an exact marker:</p>
0x0 ABI 0.1</span></span></code></pre>
Direct ELF binaries append that marker as a NUL-terminated
string. Relocatable objects carry it in .note.0x0.abi</code>. The
linker rejects inputs with a different marker and appends
the accepted marker to linked output.</p>
That marker is doing the same kind of work as the unixlib
exported symbol array, but at a different layer. It is a
cheap, inspectable way to say: this artifact claims to speak
this binary contract.</p>
The current runtime value ABI is intentionally small:</p>
payload: rax</span></span>
tag:     r15</span></span></code></pre>
Current direct-ELF tags are:</p>
0 = Unit / nil</span></span>
1 = I64 or Bool payload</span></span>
2 = NUL-terminated UTF-8 Text pointer</span></span>
3 = cons/list pointer</span></span></code></pre>
Function returns use rax</code> and r15</code>. Function arguments
use paired payload and tag registers for up to six arguments.
Payloads go through the normal x86-64 argument registers:</p>
arg0 rdi</span></span>
arg1 rsi</span></span>
arg2 rdx</span></span>
arg3 rcx</span></span>
arg4 r8</span></span>
arg5 r9</span></span></code></pre>
Tags use another register set:</p>
arg0 r10</span></span>
arg1 r11</span></span>
arg2 r12</span></span>
arg3 r13</span></span>
arg4 r14</span></span>
arg5 r15</span></span></code></pre>
There is no vague "and then more arguments go somewhere"
clause in ABI 0.1</code>. More than six arguments are rejected
by the current direct ELF path. That is a good thing.
A small ABI with a clear failure mode is better than a
larger ABI that exists only as compiler behavior nobody
has written down yet.</p>
Text values are NUL-terminated UTF-8. Lists are cons
cells. A cons node is a 24-byte record:</p>
offset 0  = car payload</span></span>
offset 8  = car tag</span></span>
offset 16 = cdr payload</span></span></code></pre>
Allocation in the direct ELF runtime is process-lifetime
allocation backed by Linux syscalls such as mmap</code>.
There is no ABI 0.1</code> garbage collector hiding behind the
scenes. Again, that limitation is useful because it is
explicit.</p>
Direct ELF: Writing The Process Image</strong></p>
One of the more satisfying parts of 0x0</code> is that direct
ELF output is literal. The compiler emits ELF64/x86-64
bytes as hex text, then the wrapper turns that hex into
an executable file.</p>
In compiler2/elf-runtime.0x0</code>, the ELF helper writes the
ELF magic bytes, ET_EXEC</code>, machine x86-64</code>, an entry
point, one program header, and one PT_LOAD</code> image.
The compatibility compiler has the same spirit: comments in
compiler/compat-main.0x0</code> say the backend writes a single
PT_LOAD</code> ELF image and serializes little-endian header
fields as hex strings because the seed and compiler paths
pass artifacts as text.</p>
That sounds primitive until you remember what an
executable needs to be at this stage. For the direct path,
0x0</code> does not need a general-purpose linker. It needs a
deterministic process image for the language slice it supports.</p>
The startup code is also part of the ABI. The direct ELF
startup initializes the runtime arena, preserves process
metadata for argv</code> and env</code>, calls main</code>, and prints
the supported result types. Compiler artifacts use a different
wrapper: they read source and output paths from process
arguments, compile, then write the output file.</p>
This is another place where API and ABI split apart. The
user writes a main</code> function. The emitted executable has
a process entry point, stack assumptions, syscall snippets,
runtime arena initialization, and result-printing behavior.
The ABI is the glue between those layers.</p>
Object Files And The Linker: Refusing To Guess</strong></p>
The object path is where 0x0</code> starts looking more like a
traditional native toolchain. It emits ELF64 ET_REL</code>
objects and links them into Linux ELF64 executables.</p>
The interesting bit is that zero-link</code> is not just a
wrapper around ld</code>. It  reads ELF section and symbol
tables itself and writes the executable itself. The current
linker accepts the compiler's object slice, resolves
symbols, applies supported relocations, lays out .text</code>,
.rodata</code>, .data</code>, and .bss</code>, and writes separate load
segments for executable and writable data.</p>
The supported relocation set is explicit. The diagnostics
are explicit. The ABI marker check is explicit.</p>
For example, objects with the wrong ABI marker are not
"probably fine". They are rejected with an ABI mismatch
diagnostic. The tests mutate a deterministic object from
0x0 ABI 0.1</code> to 0x0 ABI 9.9</code> and require the linker to
refuse it.</p>
That is the difference between a binary format and a managed
ABI. ELF lets you put the bits somewhere. The toolchain
policy decides which bits are allowed to cross the boundary.</p>
ABI As Release Evidence</strong></p>
The part I appreciate most in 0x0</code> is the amount of ABI
state that lives in plain data files:</p>

abi/VERSION</code>;</li>
abi/layout-goldens.tsv</code>;</li>
abi/value-layouts.tsv</code>;</li>
abi/backend-contract-matrix.tsv</code>;</li>
abi/diagnostic-contracts.tsv</code>;</li>
release/abi-contract-evidence.tsv</code>;</li>
compat/abi-matrix.tsv</code>.</li>
</ul>
The value layout schema separates executable/object
ABI 0.1</code> from ABI v1 value layout families. That
distinction matters. The executable marker says whether
artifacts can link and run together. The value layout
schema says how language values such as Option</code>,
Result</code>, Map</code>, Bytes</code>, Error</code>, paths, handles,
actors, sockets, closures, and host buffers are
represented when they cross runtime boundaries.</p>
Those two ideas are related, but they are not the same.
A project that merges them too early will eventually
have to answer painful questions like: did this change
break object compatibility, source compatibility,
runtime value compatibility, or only one backend's
implementation detail?</p>
0x0</code>'s answer is to make the rows separate and then
gate them:</p>

make abi-check</code> checks released artifacts and ABI
examples</li>
make abi-layout-check</code> checks the required layout
schema and docs</li>
make abi-v1-layout-check</code> checks promoted core value
layouts</li>
make abi-contract-hardening-check</code> checks the broader
ABI evidence</li>
linker and object tests check marker handling,
relocations, symbol resolution, diagnostics, and
output layout.</li>
</ul>
The tests are not just testing "does the program print 42".
They are testing whether the artifacts still speak the
same binary language.</p>
The Lesson</strong></p>
The Wine article is interesting because it shows how thin
the wall between "Windows process" and "Linux process"
can be. The wall is the ABI.</p>
The unixlib approach says: make the wall narrow and
well-shaped. Use a PE side, a normal ELF side, a known
exported function array, a dispatcher, one pointer
argument, and one status result.</p>
0x0</code> is applying the same kind of discipline to its own
compiler outputs. It does not treat "ELF" as a magic word
that makes binaries real. It defines:</p>

the target;</li>
the marker;</li>
the value representation;</li>
the call registers;</li>
the stack discipline;</li>
the object sections;</li>
the supported relocations;</li>
the linker behavior;</li>
the diagnostics;</li>
the release evidence.</li>
</ul>
That is what "managing ABI" looks like in practice. You
keep the boundary small, stamp the boundary into the
artifact, and make every tool that crosses it prove
that it understands the stamp.</p>
Maybe the most useful mental model is this:</p>
ELF is the envelope. ABI is the language inside
the envelope.</p>
If the language is underspecified, two tools can both
produce perfectly valid ELF and still fail to understand
each other. If the ABI is explicit, the tools can be
small, strict, and boring in the best possible way.</p>
That is the lesson I want to keep from both Wine and 0x0</code>:
the hard part is not always producing bytes. The hard part
is deciding which bytes are a promise.</p>
Sources And Notes</strong></p>

ArcaneNibble, "How to call Linux code from a Wine process"</a>.</li>
0x0</code> repository files inspected while writing this: README.md</code>,
docs/abi.md</code>, docs/abi-value-layouts.md</code>, docs/compiler.md</code>,
docs/linker.md</code>, docs/native-toolchain.md</code>, compiler2/elf-runtime.0x0</code>,
compiler2/object-format.0x0</code>, compiler/compat-main.0x0</code>,
tools/zero-link.py</code>, tools/zero-elf-info.py</code>, and ABI/linker tests under
tests/</code>.</li>
</ul>
Glossary</strong></p>
ABI: Application Binary Interface. The binary-level contract
for calls, values, registers, stack layout, symbols, object
files, and runtime ownership.</p>
API: Application Programming Interface. The source-level
interface a programmer uses, such as a function name,
parameters, and documented behavior.</p>
ELF: Executable and Linkable Format. The common binary file
format for Linux executables, object files, shared libraries,
segments, sections, symbols, and relocations.</p>
PE: Portable Executable. The Windows executable and DLL
file format.</p>
DLL: Dynamic Link Library. A Windows shared library.</p>
SO: Shared Object. A Unix/Linux shared library, usually
ending in .so</code>.</p>
FFI: Foreign Function Interface. A way for code written for
one language or runtime to call code written for another.</p>
GAS: GNU Assembler. The assembler syntax/tooling path used
by the compatibility object backend.</p>
SysV: System V. In this post, shorthand for the System V
x86-64 ABI used by Linux and other Unix-like systems
on x86-64.</p>
WinAPI: Windows API. The operating-system API exposed
by Windows.</p>
WOW64: Windows-on-Windows 64-bit. The Windows subsystem
for running 32-bit Windows code on 64-bit Windows; Wine
has analogous concerns for 32-bit-on-64-bit support.</p>
libc: The C standard library implementation used by a
Unix-like system, often also exposing POSIX and
Linux-specific functions.</p>
POSIX: Portable Operating System Interface. A family of
Unix-like operating system API standards.</p>
mmap</code>: A Unix/Linux system call used to map memory
into a process address space.</p>
DT_*</code>: ELF dynamic table tags, such as DT_SYMTAB</code>
and DT_STRTAB</code>.</p>
PT_*</code>: ELF program header types, such as PT_LOAD</code>
and PT_DYNAMIC</code>.</p>
ET_*</code>: ELF file types, such as ET_EXEC</code> and ET_REL</code>.</p>
PT_LOAD</code>: An ELF program header type telling the loader
to map a segment into memory.</p>
PT_DYNAMIC</code>: An ELF program header type pointing to
dynamic linking metadata.</p>
ET_EXEC</code>: An ELF file type for executable files.</p>
ET_REL</code>: An ELF file type for relocatable object
files.</p>
PLT: Procedure Linkage Table. ELF machinery commonly used
for calls that are resolved through dynamic linking.</p>
GOT: Global Offset Table. ELF machinery commonly used
to hold addresses needed by position-independent and
dynamically linked code.</p>
NUL: The zero byte, often used to terminate C strings.</p>
UTF-8: Unicode Transformation Format 8-bit. A byte
encoding for Unicode text.</p>
OISA: The intermediate instruction set used by 0x0</code>
in its compiler pipeline.</p>


0x0, Technically
2026-06-21T00:00:00+00:00
Technically as I see it.</p>
The language looks like a Lisp:</p>
;;; A source contract plus a pure effect boundary.</span></span>
(</span>⊙</span> examples.add)</span></span>
</span>
(</span>ƒ</span> add</span></span>
  (</span>∷</span> (</span>→</span> I64</span> I64</span> I64</span>)</span>)</span></span>
  (</span>cap</span> pure</span>)</span></span>
  (</span>doc</span> "Return the sum of two integers."</span>)</span></span>
  (</span>a b)</span></span>
  (</span>+</span> a b)</span>)</span></span>
</span>
(</span>ƒ</span> main</span></span>
  (</span>∷</span> (</span>→</span> Unit</span> I64</span>)</span>)</span></span>
  (</span>cap</span> pure</span>)</span></span>
  (</span>_)</span></span>
  (</span>add 20</span> 22</span>)</span>)</span></span></code></pre>
The colors here follow the same token families as the
project's editor support: comments, strings, numbers,
delimiters, keywords, constants, types, functions,
and operators.</p>
0x0 is a small symbolic functional kernel whose
compiler is written in 0x0 from the beginning.
The assembly seed is kept around as a
recovery/audit path. The normal point of gravity
is compiler/main.0x0</code>.</p>
The project:</p>
compiler/main.0x0 -> stage1.oisa</span></span>
stage1.oisa      -> stage2.oisa</span></span>
stage2.oisa      -> stage3.oisa</span></span>
</span>
stage2.oisa == stage3.oisa</span></span></code></pre>
That comparison is the self-hosting gate.
If stage 2 and stage 3 disagree,
the compiler is not actually preserving itself.</p>
That is the part I like.</p>
0x0 starts with the parts almost aggressively:
bootstrap boundary, compiler succession, ABI notes,
object metadata, linker diagnostics, release
hashes, and compatibility gates.</p>
A file is a sequence of parenthesized forms.
(⊙ name)</code> declares the module.
(ƒ name ...)</code> declares a function.
∷</code> declares a checked source contract.
cap</code> declares what kind of effects the function
is allowed to reach.
doc</code> is source metadata for generated API docs.
≔</code> introduces local bindings.
if</code> and do</code> are the control surface.</p>
The current value world is:</p>

I64</code></li>
Text</code></li>
Bool</code></li>
Unit</code></li>
cons-style lists</li>
</ul>
The current builtin world is useful but still small:
arithmetic, comparison, list operations,
text operations, stdin/stdout, argv/env,
file read/write, print</code>, and panic</code>.</p>
The type checker rejects malformed function shapes,
duplicate declarations, unbound symbols,
call arity errors, builtin arity errors,
obvious concrete type mismatches, bad if</code>
conditions when known, and pure/effect boundary
violations.</p>

unannotated functions default to io</code></li>
(cap pure)</code> functions may call pure functions
and pure builtins</li>
pure functions cannot call read-file</code>,
write-file</code>, read-stdin</code>, argv</code>, env</code>, print</code>,
panic</code>, or non-pure user functions</li>
</ul>
Local packages are manifest and lockfile backed:</p>
;;; Local package imports resolve through 0x0.lock.</span></span>
(</span>⊙</span> examples.core_data)</span></span>
(</span>↥</span> "pkg:core-map"</span>)</span></span>
(</span>↥</span> "pkg:core-json"</span>)</span></span>
(</span>↥</span> "pkg:core-result"</span>)</span></span>
</span>
(</span>ƒ</span> main</span></span>
  (</span>∷</span> (</span>→</span> Unit</span> I64</span>)</span>)</span></span>
  (</span>_)</span></span>
  (</span>≔</span> (</span>(</span>m (</span>map-put</span> (</span>map-empty</span> Unit</span>)</span> "base"</span> 35</span>)</span>)</span></span>
      (</span>base (</span>option-value-or</span> (</span>map-get</span> m "base"</span>)</span> 0</span>)</span>)</span></span>
      (</span>from-json (</span>option-value-or</span> (</span>json-get-int</span> "{\"n\":7}"</span> "n"</span>)</span> 0</span>)</span>)</span>)</span></span>
    (</span>+</span> base from-json)</span>)</span>)</span></span></code></pre>
The package layer is a local manifest plus a checked
lockfile. That is still useful because it gives
imports a stable name before the project grows a
registry around them.</p>
The direct ELF ABI uses a payload plus a tag:</p>
rax = value payload</span></span>
r15 = value tag</span></span>
</span>
0 = Unit / nil</span></span>
1 = I64 or Bool</span></span>
2 = NUL-terminated UTF-8 Text pointer</span></span>
3 = cons/list pointer</span></span></code></pre>
Direct ELF output is Linux x86-64 today. It can emit
integer/control-flow code, calls, recursion, locals,
text operations, list operations, file/stdin/stdout
operations, and compiler artifacts. There is also a
C compatibility path, a GAS/object compatibility path,
a direct object writer slice, an archive writer,
a linker, and an optimizer with small verified passes.</p>
It owns enough of the pipeline to make release
engineering part of the language design:</p>

source parser and semantic validator</li>
OISA backend for self-hosting</li>
C compatibility backend</li>
direct ELF64/x86-64 executable backend</li>
object/archive/linker slices</li>
ABI marker checks</li>
optimizer pass registry</li>
diagnostics classes</li>
generated API docs from source annotations</li>
independent compiler work for cross-checking</li>
</ul>
So what is 0x0, technically?</p>
It is a self-hosting language kernel where the
compiler trust path is the main feature. It is a
small source language wrapped around an auditable
native toolchain experiment. It is not yet</em> mature
enough yet to be your batteries included app stack.</p>
That is the kind of weird I respect.</p>


jmp0x1b
2026-06-13T00:00:00+00:00
I decided to focus all my energy on my desire to become a
galactic civilization.</p>
Yes, it's stupid and naive. And you are right to believe
that. Only a fool would like to help me with such an
impossible and naive dream.</p>
I just don't care anymore about the human experiment.</p>
I came down to Earth to have experiences and live by my
own sword. I have failed most of my life in doing that.</p>
'Nuff.</p>
I will die working on https://jmp0x1b.com</a></p>
and I'm happy with that path. My path. My only path.</p>
I'll be writing about the engineering challenges.</p>
If you care, come back and enjoy it.</p>


Hardware Memory
2025-10-19T00:00:00+00:00
I recently binged Halt and Catch Fire again</strong>. The episode where they
reverse-engineered the BIOS took me right back to when I'd watch my dad with
his oscilloscopes like he was doing magic from another universe.
It got me thinking about chips and memory. I took a microprocessors class in
college, it was a blast.
For the first post on my new, new, new blog, I'm starting with hardware memory</a>.</p>
Memory</strong></p>
Rust doesn't magically remove the problem. What it does</em> do is give you
unusually strong leverage: safe code is designed to avoid data races (which
Rust treats as Undefined Behavior), and when you need atomics, Rust exposes
the same fundamental ordering toolbox used by other systems languages.</p>
three contracts</strong>:</p>

Hardware contract</strong>: what CPUs may do.</li>
Language contract</strong>: what the compiler may assume and reorder.</li>
Type contract</strong>: what Rust will (and won't) let you express safely.</li>
</ul>
Contract 1: Hardware does not promise as-written execution</strong></p>
Russ Cox opens his hardware memory model series with the key punchline:
optimizations that were invisible in single-threaded programs become
visible</em> with threads, and it depends becomes the default unless you have a
contract.</p>
A classic litmus test is message passing</strong>:</p>

Thread 1 # Thread 2
x = 1 r1 = y
y = 1 r2 = x</p>
</blockquote>
Can Thread 2 observe r1 = 1</code> but r2 = 0</code>?</p>

On a sequentially consistent machine: no</strong>.</li>
On x86 TSO: no</strong>.</li>
On weaker hardware like ARM/POWER: it can be yes</strong> without extra
barriers/fences.</li>
</ul>
So even before we talk about compilers, my writes become visible to other
cores in program order</em> is not a universal hardware law.
Another famous one is store buffering</strong> (a.k.a. store buffer / write queue):</p>

Thread 1 # Thread 2
x = 1 y = 1
r1 = y r2 = x</p>
</blockquote>
Can we end with r1 = 0</code> and r2 = 0</code>?</p>

Sequentially consistent: no</strong>.</li>
x86 TSO: yes</strong> (both stores sit in per-core buffers; both reads miss them).</li>
ARM/POWER: yes</strong>.</li>
</ul>
If your brain is screaming but that's illegal</em>, good, your brain is sequentially
consistent. Your CPU is not required to be.</p>
Contract 2: The language memory model is where compilers get permission</strong></p>
Even if hardware were perfectly sequentially consistent, the compiler still wants
to reorder, eliminate, and fuse loads/stores for speed. Those transformations
were invisible</em> in single-threaded code. With threads, they become visible.</p>
Language memory models generally converge on a pragmatic deal often summarized as:</p>

DRF-SC</strong>: Data-race-free programs behave as if sequentially consistent.</em></p>
</blockquote>
Russ Cox describes that as a major goal in mainstream language memory models
(Java, C/C++, Rust, etc.).</p>
But: DRF-SC is a conditional promise</strong>. If you have a data race, the language
may give you anything from we define a weak-but-sane behavior</em> (Java historically
tried) to the program has no defined meaning</em> (C/C++ land).
Rust lands firmly in the no defined meaning</em> camp for data races.</p>
Contract 3: Rust's type system tries to prevent you from writing</em> data races</strong></p>
Rust's unsafe book states it plainly:</p>

A data race is Undefined Behavior</strong></li>
And safe Rust is designed to make data races impossible to express (mostly
through ownership/borrowing; with Send</code>/Sync</code> controlling what can cross threads).</li>
</ul>
Important nuance:</p>

Rust does not</strong> prevent all</em> race conditions (logic races, lost updates,
timing bugs).</li>
It targets data races</strong>: unsynchronized concurrent access where at least
one access is a write.</li>
</ul>
This is why Rust concurrency often feels like:</p>

You don't get to share mutable stuff unless you prove how you're coordinating it.</p>
</blockquote>
And the moment you do</em> want to coordinate at a lower level (lock-free structures,
custom primitives), you end up using atomics</strong> (safe) or unsafe</code> (very sharp).</p>
Rust atomics: what they are actually for</strong></p>
Atomics are not faster mutexes</em>. They are the vocabulary</em> used to build
synchronization: the tool that creates happens-before</strong> edges and constrains
reordering.</p>
Rust's atomic orderings (Relaxed</code>, Acquire</code>, Release</code>, AcqRel</code>, SeqCst</code>) are
documented in std::sync::atomic::Ordering</code>.
Here's the practical mental model I recommend:</p>
Relaxed</code>: atomicity without ordering</strong>
Good for counters, stats, eventually consistent</em> observations.
It prevents torn reads/writes of that atomic variable, but does not promise when
other memory becomes visible.</p>
Release</code> / Acquire</code>: publish–subscribe</strong></p>

Writer: do regular work, then Release-store</strong> a flag.</li>
Reader: Acquire-load</strong> the flag, then it can safely observe what was published.</li>
</ul>
Rust docs describe Release</code> as making prior operations ordered before an Acquire</code>
load that observes that value.</p>
SeqCst</code>: the everyone agrees</em> mode</strong></p>
Same synchronization power as Acquire/Release, plus a single global order of all
SeqCst</code> operations (simplifies reasoning; can cost more).</p>
Example 1: A clean publish–subscribe in Rust (no unsafe</code>)</strong></p>
This example uses only atomics, so it stays fully safe. It shows the shape of
the pattern:</p>
use</span> std</span>::</span>sync</span>::</span>atomic</span>::</span>{</span>AtomicBool</span>,</span> AtomicUsize</span>,</span> Ordering</span>}</span>;</span></span>
use</span> std</span>::</span>sync</span>::</span>Arc</span>;</span></span>
use</span> std</span>::</span>thread</span>;</span></span>
</span>
struct</span> Shared</span> {</span></span>
    data</span>:</span> AtomicUsize</span>,</span></span>
    ready</span>:</span> AtomicBool</span>,</span></span>
}</span></span>
</span>
fn</span> main</span>(</span>)</span> {</span></span>
    let</span> s</span> =</span> Arc</span>::</span>new</span>(</span>Shared</span> {</span></span>
        data</span>:</span> AtomicUsize</span>::</span>new</span>(</span>0</span>)</span>,</span></span>
        ready</span>:</span> AtomicBool</span>::</span>new</span>(</span>false</span>)</span>,</span></span>
    }</span>)</span>;</span></span>
</span>
    let</span> t1</span> =</span> {</span></span>
        let</span> s</span> =</span> s</span>.</span>clone</span>(</span>)</span>;</span></span>
        thread</span>::</span>spawn</span>(</span>move</span> |</span>|</span> {</span></span>
            s</span>.</span>data</span>.</span>store</span>(</span>42</span>,</span> Ordering</span>::</span>Relaxed</span>)</span>;</span></span>
            s</span>.</span>ready</span>.</span>store</span>(</span>true</span>,</span> Ordering</span>::</span>Release</span>)</span>;</span></span>
        }</span>)</span></span>
    }</span>;</span></span>
</span>
    let</span> t2</span> =</span> {</span></span>
        let</span> s</span> =</span> s</span>.</span>clone</span>(</span>)</span>;</span></span>
        thread</span>::</span>spawn</span>(</span>move</span> |</span>|</span> {</span></span>
            while</span> !</span>s</span>.</span>ready</span>.</span>load</span>(</span>Ordering</span>::</span>Acquire</span>)</span> {</span>}</span></span>
            let</span> v</span> =</span> s</span>.</span>data</span>.</span>load</span>(</span>Ordering</span>::</span>Relaxed</span>)</span>;</span></span>
            assert_eq!</span>(</span>v</span>,</span> 42</span>)</span>;</span></span>
        }</span>)</span></span>
    }</span>;</span></span>
</span>
    t1</span>.</span>join</span>(</span>)</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    t2</span>.</span>join</span>(</span>)</span>.</span>unwrap</span>(</span>)</span>;</span></span>
}</span></span></code></pre>
The Release store on ready ensures the prior write to data becomes visible
to any thread that sees ready == true</code> via an Acquire</code> load.
Where I usually go wrong: I make ready relaxed too, and then the reader can
observe the flag without observing the published data on some
platforms/optimizations, the exact it depends</em> Russ warns about.</p>
Example 2: Acquire/Release is not global sequential consistency</strong></p>
A spicy detail from the language-memory-model world: Acquire/Release does
not impose a single total order across different memory locations.
Russ Cox shows the store-buffering litmus test remains possible under
C++11 acquire/release atomics, even though it is disallowed under
sequentially consistent atomics.
That means: you can correctly synchronize publication on one atomic, and
still not get whole-program sequential consistency</em> for free.
This is why SeqCst exists: sometimes you want fewer degrees of freedom for the
machine, because you want fewer degrees of freedom in your own head.</p>
The unsafe cliff: memory ordering is only half the story</strong></p>
Memory model can be</em> two different beasts:</p>

Concurrency ordering (atomics, fences, visibility)</li>
Aliasing & provenance (what references mean; what the optimizer may assume)</li>
</ul>
Rust's aliasing rules are why &T</code> implies not being mutated</em> and &mut T</code>
implies unique</em>. When you build interior mutability (like Cell, RefCell, Mutex),
Rust requires you to go through UnsafeCell<T></code>, it’s the sanctioned escape
hatch.
Key point from the UnsafeCell docs:</p>

UnsafeCell</code> relaxes the immutability guarantee behind &T</code></li>
but it does not make aliasing &mut</code> references okay (uniqueness is still
required).</li>
</ul>
Researchers and the Rust unsafe-code community have proposed operational models
like Stacked Borrows and Tree Borrows to formalize which pointer uses are allowed
and which become UB.</p>
If you write unsafe abstractions, this is the layer that decides whether your code
is works on my machine</em> or silently illegal</em>.</p>
How to build confidence: Loom + Miri</strong></p>
Loom is a concurrency testing tool that repeatedly runs your test while exploring
possible thread schedules under the C11-style memory model used for Rust atomics
in practice.</p>

Great for: custom mutexes, channels, lock-free structures, tricky state machines.</li>
Not great for: just add Loom to everything</em> (it’s targeted, and can explode in complexity).</li>
</ul>
Miri interprets Rust and detects many classes of UB (out-of-bounds, use-after-free,
invalid aliasing patterns, etc.).</p>
If your project has unsafe, running cargo miri test is a very direct are we lying
to the compiler?</em> check.</p>
A tiny ordering cheat-sheet</strong></p>
Just sharing read-only data across threads</p>

Prefer: Arc + immutable data.</li>
No atomics needed.</li>
</ul>
Shared mutable state</p>

Prefer: Mutex, RwLock, channels (higher-level synchronization).</li>
Atomics only when you’re building primitives or chasing specific
perf needs.</li>
</ul>
Counters / metrics</p>

Often: Relaxed.</li>
</ul>
Publish–subscribe / “ready flag”</p>

Writer: Release store</li>
Reader: Acquire load</li>
</ul>
You want the simplest reasoning model</p>

Use: SeqCst (until profiling proves you need weaker).</li>
</ul>
The hardware wants speed. The compiler wants freedom. Our job is to
write down the constraints that make your program actually mean what
you think it means.</p>
Rust helps by making accidentally racy</em> code hard to express, and by
giving you the same atomic tools used to build the rest of the ecosystem.
The cost is that when you go low-level, you're now negotiating with three
contracts at once: CPU, compiler, and Rust's own rules.</p>
i dunno what i am doing

0x0 Shared Memory

0x0 Memory

0x0 Self-Hosting Without The C Detour

0x0 Distribution

ABI 0x0

0x0, Technically

jmp0x1b

Hardware Memory
