<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
<title>Zipp Engineering Journal: Building a JavaScript Engine in Rust</title>
<link>https://www.zipp.org/journal/</link>
<atom:link href="https://www.zipp.org/journal/feed.xml" rel="self" type="application/rss+xml"/>
<description>Dated engineering notes from the Zipp repository since 29 May 2026: the pivot to JavaScript, the Test262 climb, the performance campaign, audits and the Python frontend.</description>
<language>en</language>
<lastBuildDate>Mon, 14 Sep 2026 00:00:00 GMT</lastBuildDate>
<image><url>https://www.zipp.org/zipp-og-card.png</url><title>Zipp Engineering Journal: Building a JavaScript Engine in Rust</title><link>https://www.zipp.org/journal/</link></image>
<item>
<title>95,671 unmodified, 95,680 corrected, and v0.0.18</title>
<link>https://www.zipp.org/journal/corrected-core-conformance-and-v0-0-18/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/corrected-core-conformance-and-v0-0-18/</guid>
<pubDate>Mon, 14 Sep 2026 00:00:00 GMT</pubDate>
<category>conformance</category>
<category>release</category>
<description>The pinned Test262 corpus passes 95,671 of 95,680 executions unmodified and 95,680 of 95,680 with five documented corrections; the DateTimeFormat shard passes 488 of 488; v0.0.18 is published.</description>
<content:encoded><![CDATA[<p>The pinned Test262 corpus passes 95,671 of 95,680 executions unmodified and 95,680 of 95,680 with five documented corrections; the DateTimeFormat shard passes 488 of 488; v0.0.18 is published.</p>
<p>The morning began at 95,669 pass, 11 fail, 0 skip on a hosted run whose notes say, in so many words, &quot;This is not a 100% conformance result.&quot; An Annex B fix (<code>9f9e3d56</code>) found a real hidden defect behind an obsolete expectation: a block function was not visible before its textual declaration. Then <code>1539eb4b</code> completed the pinned <code>Intl.DateTimeFormat</code> shard with generated CLDR 48 data and reported the corrected core profile separately from the unmodified one.</p>
<p>The nine remaining unmodified failures are contradictions inside the pinned corpus, corrected by five patches with recorded hashes; Node 24.19 fails four of the same executions. v0.0.18 (<code>fc474d15</code>, the repository&#39;s only pull-request merge) shipped with the first WebAssembly archive that includes Python. The landing page was updated to show both numbers.</p>]]></content:encoded>
</item>
<item>
<title>A documentation site, a sitemap and this journal</title>
<link>https://www.zipp.org/journal/documentation-site-and-journal/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/documentation-site-and-journal/</guid>
<pubDate>Mon, 14 Sep 2026 00:00:00 GMT</pubDate>
<category>site</category>
<description>zipp.org gains crawlable pages for the engine, Python, WebAssembly, GPU compute, Test262, benchmarks and architecture, all rendered from one JSON file, plus this journal with an RSS feed.</description>
<content:encoded><![CDATA[<p>zipp.org gains crawlable pages for the engine, Python, WebAssembly, GPU compute, Test262, benchmarks and architecture, all rendered from one JSON file, plus this journal with an RSS feed.</p>
<p>Until today zipp.org was a single React page whose text lived inside a JavaScript bundle. It now has static HTML pages for the <a href="/javascript-engine/">JavaScript engine</a>, <a href="/python/">Python</a>, <a href="/wasm/">WebAssembly</a>, <a href="/webgpu/">GPU compute</a>, <a href="/test262/">Test262</a>, <a href="/benchmarks/">benchmarks</a>, <a href="/architecture/">architecture</a>, <a href="/embedding/">embedding</a>, <a href="/sandbox/">sandboxing</a>, <a href="/comparisons/">comparisons</a>, <a href="/releases/">releases</a>, <a href="/journey/">the story</a> and three long-form <a href="/articles/">articles</a>, each with its own title, description, canonical URL, breadcrumbs and structured data.</p>
<p>Every word of those pages is in one file, <code>landing/site/content.json</code>, and a small renderer turns it into HTML at build time, so the text is in the served document before any script runs. The same build writes <code>sitemap.xml</code>, <code>robots.txt</code>, a real <code>404.html</code>, the journal&#39;s RSS feed and a search index. Unknown URLs now return a genuine 404 instead of a copy of the home page.</p>]]></content:encoded>
</item>
<item>
<title>Python, WASM variants, the playground and GPU compute in one day</title>
<link>https://www.zipp.org/journal/python-frontend-playground-and-gpu/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/python-frontend-playground-and-gpu/</guid>
<pubDate>Sun, 13 Sep 2026 00:00:00 GMT</pubDate>
<category>python</category>
<category>gpu</category>
<category>wasm</category>
<category>playground</category>
<description>The experimental Python 3 frontend lands, compiling to the same register bytecode as JavaScript, together with WASM build variants, a folder-based playground, GPU graphs from Python and a Torch subset with GPU training.</description>
<content:encoded><![CDATA[<p>The experimental Python 3 frontend lands, compiling to the same register bytecode as JavaScript, together with WASM build variants, a folder-based playground, GPU graphs from Python and a Torch subset with GPU training.</p>
<p><code>378b18de</code> adds the Python frontend, the <code>javascript</code> and <code>all</code> WebAssembly variants and the playground. <code>5fd22bcb</code> is titled &quot;Python: Zipp&#39;s own full-language implementation&quot;: the RustPython parser for the AST, Zipp&#39;s own symbol table and emitter to register bytecode, and a JavaScript-shaped runtime for the object model, validated byte for byte against CPython on a committed corpus.</p>
<p><code>8bb14918</code> integrates the GPU Lab so Python graphs can execute on WebGPU, WebGL2, compiled WASM kernels or JavaScript. <code>9651dd40</code> makes Python projects folders, adds the Torch subset and puts the lab in the playground. <code>955914f3</code> adds asynchronous dense GPU training through <code>torch.compile(step, training=True)</code> and pins down the virtual-filesystem change protocol. The docs are careful: a Python and Torch subset, not CPython or PyTorch.</p>]]></content:encoded>
</item>
<item>
<title>v0.0.16 and v0.0.17: audited engine hardening</title>
<link>https://www.zipp.org/journal/v0-0-16-and-v0-0-17-audited-hardening/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/v0-0-16-and-v0-0-17-audited-hardening/</guid>
<pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate>
<category>release</category>
<category>security</category>
<category>audit</category>
<description>Two releases close 38 tickets from the 11 September audits: VM rooting, coercion, TypedArray semantics, parser, GC and metadata, while preserving the exact 95,939 of 95,942 result on the previous corpus.</description>
<content:encoded><![CDATA[<p>Two releases close 38 tickets from the 11 September audits: VM rooting, coercion, TypedArray semantics, parser, GC and metadata, while preserving the exact 95,939 of 95,942 result on the previous corpus.</p>
<p>The correctness audit starting from <code>ee107d4b</code> (v0.0.16) found host values and exceptions lost across a callable Proxy&#39;s <code>apply</code> getter, a structured argument returned as <code>Opaque</code> and a string as an unrelated <code>Date</code>, TypedArray species and byte-copy semantics, and six reproduced defect regressions. The follow-up covered <code>ArrayBuffer</code>, <code>SharedArrayBuffer</code> and <code>DataView</code> re-entrancy, a CAS retry in <code>SharedArrayBuffer.prototype.grow</code>, strict <code>ToNumber</code> versus BigInt across a dozen algorithms, Promise combinators and iterator closing.</p>
<p>v0.0.17 (<code>127477bd</code>) is &quot;audited engine hardening&quot;. Both audit reports are in <code>docs/audits/</code>, and the scorer fix that came with them exposed 42 false passes in the older corpus (95,897 of 95,942 before the fixes, 95,939 after).</p>]]></content:encoded>
</item>
<item>
<title>Two audits, exact-revision CI gating, and a capture that got slower</title>
<link>https://www.zipp.org/journal/two-audits-ci-gating-and-a-slower-capture/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/two-audits-ci-gating-and-a-slower-capture/</guid>
<pubDate>Fri, 11 Sep 2026 00:00:00 GMT</pubDate>
<category>security</category>
<category>audit</category>
<category>ci</category>
<category>performance</category>
<description>Embedding-API and host-boundary audit findings are fixed, browser Worker smoke tests and a reference host adapter land, releases are gated on the exact tagged commit, and a fresh benchmark capture shows the cost of strict call order.</description>
<content:encoded><![CDATA[<p>Embedding-API and host-boundary audit findings are fixed, browser Worker smoke tests and a reference host adapter land, releases are gated on the exact tagged commit, and a fresh benchmark capture shows the cost of strict call order.</p>
<p><code>014c1b70</code> and <code>cfb83cf3</code> fix the 11 September audit&#39;s embedding-API and host-boundary findings. <code>b92a268c</code> adds browser Worker smoke tests and a reference host adapter tested in real Chromium, Firefox and WebKit Workers. <code>ab56a840</code> and <code>14770703</code> rework CI: exact-revision release gating, an accountable quarantine, scheduled security checks, and a minimum gate on push with the heavy suites as local commands and a weekly security run.</p>
<p>The canonical capture at <code>14770703</code> (zipp 0.0.15) is publishable and worse: headline ten rows at 1.003× Node against 0.878× on 2 September, with <code>bytecode-vm</code> at 3.59×. A paired A/B against the audited baseline puts the baseline within 1% of the new build on every row, so the regression opened earlier, and the suspect is v0.0.15&#39;s switch to specification-order method calls by default. The ledger records the trade instead of hiding the capture.</p>
<p>The first run on the newly pinned Test262 corpus also landed today: 95,665 of 95,680, then 95,669 after two JIT-only defects were fixed the same day.</p>]]></content:encoded>
</item>
<item>
<title>v0.0.15: the audit response, and spec-order calls by default</title>
<link>https://www.zipp.org/journal/v0-0-15-the-audit-response/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/v0-0-15-the-audit-response/</guid>
<pubDate>Mon, 07 Sep 2026 00:00:00 GMT</pubDate>
<category>release</category>
<category>correctness</category>
<description>Method calls now evaluate in specification order by default; the fused lowering that could be observed by a getter or proxy trap is used only where argument shapes provably cannot see it.</description>
<content:encoded><![CDATA[<p>Method calls now evaluate in specification order by default; the fused lowering that could be observed by a getter or proxy trap is used only where argument shapes provably cannot see it.</p>
<p>v0.0.15 (<code>e6e0f65d</code>) bundles tickets B280 through B288: spec-order method calls by default, an accel spec grammar, transactional <code>host.call</code>, <code>zippProfile()</code> so a host can tell which build it loaded, and a CI gate. B280 is the one with a price: <code>ZIPP_RELAXED_CALL_ORDER=1</code> still exists as a diagnostic and is documented as observably wrong for a getter or proxy trap, and it will never ship. The performance cost showed up in the 11 September capture.</p>]]></content:encoded>
</item>
<item>
<title>The accel bridge, and five WebAssembly interpreter cliffs closed</title>
<link>https://www.zipp.org/journal/accel-bridge-and-five-wasm-cliffs/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/accel-bridge-and-five-wasm-cliffs/</guid>
<pubDate>Sat, 05 Sep 2026 00:00:00 GMT</pubDate>
<category>wasm</category>
<category>performance</category>
<category>release</category>
<description>v0.0.14 adds the accel bridge; paired A/B measurements close five WASM interpreter pathologies, including a join with 300K retained strings from 8,423 ms to 138 ms.</description>
<content:encoded><![CDATA[<p>v0.0.14 adds the accel bridge; paired A/B measurements close five WASM interpreter pathologies, including a join with 300K retained strings from 8,423 ms to 138 ms.</p>
<p>Tickets B274 to B278, measured as diagnostic A/Bs on one machine: a 64K non-ASCII <code>charCodeAt</code> loop 4,462 → 3.2 ms; a tokenizer 9,828 → 8.2 ms; a <code>slice</code> loop 449 → 4.3 ms; <code>join</code> with 300K retained strings 8,423 → 138 ms; a <code>new Function</code> property loop 20.9 → 14.8 ms; a named-property array read 13.3 → 9.6 ms. None of these are headline numbers; all of them were cliffs a real embedder could fall off.</p>]]></content:encoded>
</item>
<item>
<title>The canonical capture: 0.728× Node across thirty rows</title>
<link>https://www.zipp.org/journal/the-canonical-capture/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/the-canonical-capture/</guid>
<pubDate>Wed, 02 Sep 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<category>release</category>
<description>v0.0.11 and v0.0.12 land register classes for tokenizer loops and inline stores into young dense arrays; the clean PGO capture at 8229b3fc becomes the public benchmark, with 21 of 30 rows faster than Node.</description>
<content:encoded><![CDATA[<p>v0.0.11 and v0.0.12 land register classes for tokenizer loops and inline stores into young dense arrays; the clean PGO capture at 8229b3fc becomes the public benchmark, with 21 of 30 rows faster than Node.</p>
<p>v0.0.11 (<code>9409b8d5</code>): register classes keep tokenizer loops on the INT tier, taking <code>parse-large-js</code> from 1.24× to 0.88× Node, and a forced-JIT segfault on a user-overridden <code>Math.random</code> is fixed. v0.0.12 (<code>13aa7e63</code>): inline stores into pinned young dense arrays and <code>x | 0</code> fused into the wrapping add. <code>b36702a4</code> publishes the <code>8229b3fc</code> capture: headline ten 0.878×, all 13 normal rows 0.614×, hostile 17 0.829×, all 30 equal-row 0.728× Node, 0.594× Bun, 0.460× Deno, with 15 counterbalanced repetitions and 10,000 bootstrap samples.</p>
<p>Nine rows still lose to Node, led by reactish-reconcile at 1.578×, allocation-survival at 1.559× and warm-router at 1.520×. The artifacts print <code>FASTER_THAN_NODE_ON_EVERY_ROW=0</code>.</p>]]></content:encoded>
</item>
<item>
<title>v0.0.5 to v0.0.10: limits sized for applications, not snippets</title>
<link>https://www.zipp.org/journal/limits-sized-for-applications/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/limits-sized-for-applications/</guid>
<pubDate>Tue, 01 Sep 2026 00:00:00 GMT</pubDate>
<category>release</category>
<category>wasm</category>
<description>Six releases in one day, each raising a ceiling a real embedder had hit: a 32 MiB ArrayBuffer, a renewable instruction budget, byte-scheduled collections, a 512 MB heap.</description>
<content:encoded><![CDATA[<p>Six releases in one day, each raising a ceiling a real embedder had hit: a 32 MiB ArrayBuffer, a renewable instruction budget, byte-scheduled collections, a 512 MB heap.</p>
<p>The tag messages read like a bug tracker for a product that had just met its users. v0.0.7 (<code>d69c7b7b</code>) raised the hardened <code>ArrayBuffer</code> ceiling from 1 MB to 32 MiB: &quot;an 8 MB Game Boy cartridge and a single 8.5 s frame of 48 kHz audio were both impossible.&quot; v0.0.8 (<code>32680f06</code>) added <code>renewInstructionBudget</code>, because a 50-million-instruction lifetime budget &quot;was a fuse on every long-running embedder.&quot; v0.0.9 (<code>d0c783b1</code>) schedules collections on bytes, not only allocation count: &quot;An emulator encoding a 23 KB framebuffer per frame died ninety seconds into a game.&quot; v0.0.10 (<code>ddbf7cd9</code>) sized the instance ceiling at 1 GB and the heap budget at 512 MB.</p>]]></content:encoded>
</item>
<item>
<title>v0.0.2 to v0.0.4: the boundary tax</title>
<link>https://www.zipp.org/journal/four-releases-and-the-boundary-tax/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/four-releases-and-the-boundary-tax/</guid>
<pubDate>Mon, 31 Aug 2026 00:00:00 GMT</pubDate>
<category>wasm</category>
<category>performance</category>
<category>release</category>
<description>The host boundary stops walking the whole heap per re-entry; an O(heap) walk is removed from the interpreter-only WASM build; JSON.stringify ×4000 drops from 919 ms to 8.5 ms; wasm-opt is dropped after measurement.</description>
<content:encoded><![CDATA[<p>The host boundary stops walking the whole heap per re-entry; an O(heap) walk is removed from the interpreter-only WASM build; JSON.stringify ×4000 drops from 919 ms to 8.5 ms; wasm-opt is dropped after measurement.</p>
<p>The day after the first release, the first embedders&#39; workloads exposed the cost of crossing into the VM. v0.0.2 (<code>a70cef47</code>) stopped the host boundary from walking the whole heap on every re-entry and raised parser sandbox limits that had rejected real code. v0.0.3 (<code>d71168a9</code>) removed another O(heap) walk, took <code>JSON.stringify</code> ×4000 from 919 ms to 8.5 ms, shrank the bundle from 6,018,862 to 5,668,533 raw bytes, dropped <code>wasm-opt</code> because <code>-Oz</code> measured smaller raw but larger on the wire and slower, and pre-warmed the playground Worker after finding that a 68 ms delay was V8 compiling, not the engine. v0.0.4 (<code>769c68ce</code>) added <code>getGlobalsFingerprint</code>, a content digest so a mutation through a reference cannot be missed, cutting per-tick host sync from 9.6 ms to 2.1 ms.</p>]]></content:encoded>
</item>
<item>
<title>v0.0.1: first distribution, README redesign, ledger archived</title>
<link>https://www.zipp.org/journal/v0-0-1-first-distribution/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/v0-0-1-first-distribution/</guid>
<pubDate>Sun, 30 Aug 2026 00:00:00 GMT</pubDate>
<category>release</category>
<category>performance</category>
<category>conformance</category>
<description>The first native and WebAssembly release; B249 takes bytecode-vm from 3.68× to 0.93× Node; module cycle roots restore 95,939 of 95,942; the performance ledger is archived at 881 KB.</description>
<content:encoded><![CDATA[<p>The first native and WebAssembly release; B249 takes bytecode-vm from 3.68× to 0.93× Node; module cycle roots restore 95,939 of 95,942; the performance ledger is archived at 881 KB.</p>
<p><code>96dac4e1</code> is tagged v0.0.1. <code>be2f5ed4</code> (B249) records the retained-ten suite at 0.918× Node and hostile at 0.866×, with <code>bytecode-vm</code> from 3.68× to 0.93× and <code>warm-router</code> from 2.18× to 1.62×. <code>8ac5cc73</code> computes module <code>[[CycleRoot]]</code> at depth-first-search time and restores three Test262 rows, back to 95,939 of 95,942. <code>ce488bbe</code> archives the campaign ledger (B001 to B252, mostly negative results, with a header warning that its earliest sections were written at 3.31× and have since been refuted), and <code>ac183cff</code> redesigns the README around measurements.</p>]]></content:encoded>
</item>
<item>
<title>A 2.16× regression, root-caused and reversed in a day</title>
<link>https://www.zipp.org/journal/a-two-point-one-six-times-regression-reversed/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/a-two-point-one-six-times-regression-reversed/</guid>
<pubDate>Sat, 29 Aug 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<category>correctness</category>
<category>conformance</category>
<description>A de-fused CallMethod lowering spikes the headline to 2.157× Node and drifts 24 Test262 rows; both are traced to one commit and reversed.</description>
<content:encoded><![CDATA[<p>A de-fused CallMethod lowering spikes the headline to 2.157× Node and drifts 24 Test262 rows; both are traced to one commit and reversed.</p>
<p>The capture on 29 August came in at 2.157× Node on the headline ten, from 0.965× the day before. The cause was <code>85fca98a</code>, which de-fused the <code>CallMethod</code> lowering; <code>e2250fca</code> separately traced a 24-row Test262 drift to the same change. <code>271647ad</code> reversed it (0.977× headline, 0.665× all 13). The same call-order question came back in September as B280, this time resolved in favour of correctness and with the cost measured.</p>]]></content:encoded>
</item>
<item>
<title>The hostile corpus goes under parity</title>
<link>https://www.zipp.org/journal/hostile-corpus-under-parity/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/hostile-corpus-under-parity/</guid>
<pubDate>Thu, 27 Aug 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<description>The 17-row hostile suite, built to make JavaScript stop looking like an ideal reducer, records a geomean of 0.961× Node for the first time.</description>
<content:encoded><![CDATA[<p>The 17-row hostile suite, built to make JavaScript stop looking like an ideal reducer, records a geomean of 0.961× Node for the first time.</p>
<p>The hostile corpus pairs six baselines with six stressors (closures, megamorphic shapes, type churn, throw-catch, surviving allocation, long-lived async) and adds five applications including a React-style reconciler, a warm router, a bytecode VM, a hot module graph and the unmodified <code>nanoid</code> package. Its first captures on 26 August were 1.111× and 1.029×; <code>af7289f1</code> records 0.961×, &quot;UNDER PARITY (first in series)&quot;, and the next two days reach 0.937× and 0.920×.</p>]]></content:encoded>
</item>
<item>
<title>Sandbox hardening for untrusted code</title>
<link>https://www.zipp.org/journal/sandbox-hardening-for-untrusted-code/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/sandbox-hardening-for-untrusted-code/</guid>
<pubDate>Tue, 25 Aug 2026 00:00:00 GMT</pubDate>
<category>security</category>
<category>arm64</category>
<description>The native and WebAssembly sandboxes are hardened for arbitrary hostile input, one day after ARM64 gets its first JIT tier.</description>
<content:encoded><![CDATA[<p>The native and WebAssembly sandboxes are hardened for arbitrary hostile input, one day after ARM64 gets its first JIT tier.</p>
<p><code>e89612a6</code> (24 August) hardens the sandboxes and adds the guarded ARM64 baseline JIT: bounded call-free integer functions and numeric loops with exact-ip fallback, no helpers, no OSR yet, and a bespoke W^X path on Windows ARM64. <code>4195e063</code> continues the hardening for untrusted code: compile-time <code>forbid(unsafe_code)</code> under <code>safe-sandbox</code>, a compile error if <code>safe-sandbox</code> and <code>jit</code> are combined, and separate workspaces so feature unification cannot reintroduce a JIT.</p>]]></content:encoded>
</item>
<item>
<title>Crossing Node parity at 0.9695×</title>
<link>https://www.zipp.org/journal/crossing-node-parity/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/crossing-node-parity/</guid>
<pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<description>Wave 19 decomposes the three rows that were 60% of the remaining gap on 23 August; the next day the headline ten rows record 0.9695× Node.</description>
<content:encoded><![CDATA[<p>Wave 19 decomposes the three rows that were 60% of the remaining gap on 23 August; the next day the headline ten rows record 0.9695× Node.</p>
<p><code>0f1a4c71</code> (23 August) is &quot;wave 19 -- the three rows nobody had decomposed were 60% of the gap&quot;, at 1.0997×. <code>c6ffa200</code>, the next day, is &quot;bench: cross Node parity at 0.9695x&quot;. Fifty-six days earlier the same suite had been at 4.20×.</p>]]></content:encoded>
</item>
<item>
<title>A tier-differential fuzzer finds five live wrong-answer classes</title>
<link>https://www.zipp.org/journal/tier-differential-fuzzer/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/tier-differential-fuzzer/</guid>
<pubDate>Fri, 21 Aug 2026 00:00:00 GMT</pubDate>
<category>correctness</category>
<category>jit</category>
<description>Running the same programs through the interpreter and every JIT tier and diffing the outputs finds five classes of silent wrong answers.</description>
<content:encoded><![CDATA[<p>Running the same programs through the interpreter and every JIT tier and diffing the outputs finds five classes of silent wrong answers.</p>
<p>The engine had already learned this lesson once in June, when an adversarial audit of the JIT found six soundness bugs, and again on 13 June when &quot;the INT tier was silently returning wrong answers on ordinary loops -- a dense-array tag check scratched a live Bool home register&quot;. <code>ee14c71d</code> makes the check systematic: a fuzzer that runs generated programs in every tier and diffs the results, which found five more classes. A later commit found that &quot;the operand table was blind to 185 of 221 opcodes -- 23 wrong-answer shapes, one root cause&quot;.</p>]]></content:encoded>
</item>
<item>
<title>The first capture under 1.20× Node</title>
<link>https://www.zipp.org/journal/first-capture-under-1-20x/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/first-capture-under-1-20x/</guid>
<pubDate>Thu, 20 Aug 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<description>1.196× on the headline ten, with typedarray-math reaching Node parity for the first time.</description>
<content:encoded><![CDATA[<p>1.196× on the headline ten, with typedarray-math reaching Node parity for the first time.</p>
<p><code>cdf064c4</code>: &quot;the wave-13 capture on the PGO build -- 1.2511x -&gt; 1.1962x [1.192, 1.201], the first capture under 1.20x; typedarray-math reaches node parity&quot;. The double tier&#39;s unboxed register homes are what carried it.</p>]]></content:encoded>
</item>
<item>
<title>The nursery goes default-on</title>
<link>https://www.zipp.org/journal/nursery-goes-default-on/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/nursery-goes-default-on/</guid>
<pubDate>Wed, 19 Aug 2026 00:00:00 GMT</pubDate>
<category>gc</category>
<category>performance</category>
<description>After a two-week pause, the non-moving generational nursery is enabled by default, taking the headline capture from 1.283× to 1.212× Node.</description>
<content:encoded><![CDATA[<p>After a two-week pause, the non-moving generational nursery is enabled by default, taking the headline capture from 1.283× to 1.212× Node.</p>
<p>The log had been quiet since 4 August. <code>74d03d23</code> is &quot;the nursery goes default-on&quot;: minor collections trace young reachability plus remembered old-to-young edges; promotion is a bookkeeping change on the same heap index because the collector never moves objects. The wave-9 capture moved from 1.2832× to 1.2117×. <code>ZIPP_NO_NURSERY=1</code> keeps the majors-only mode for conformance runs and ablations.</p>]]></content:encoded>
</item>
<item>
<title>The nursery lands (stage 1 refuted, stage 3 proven); zipp.org goes up</title>
<link>https://www.zipp.org/journal/nursery-built-and-the-landing-page/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/nursery-built-and-the-landing-page/</guid>
<pubDate>Tue, 04 Aug 2026 00:00:00 GMT</pubDate>
<category>gc</category>
<category>site</category>
<description>The generational nursery&#39;s first stage is refuted by its own measurements before the third stage lands with a prover; the first landing page is committed the same day.</description>
<content:encoded><![CDATA[<p>The generational nursery&#39;s first stage is refuted by its own measurements before the third stage lands with a prover; the first landing page is committed the same day.</p>
<p><code>NURSERY_DESIGN.md</code> was written when GC looked dominant; the ledger later corrected that (&quot;GC is 2-12%, not dominant — B81 corrected&quot; and &quot;it is the COLLECTOR, not the allocator — pool built, measured zero, reverted&quot;). Stage 1 of the nursery was refuted; stage 3 (<code>82e454fa</code>, <code>72cb640f</code>) landed with a prover that verifies remembered-set invariants, <code>ZIPP_NURSERY_VERIFY=1</code>. The design document now carries a header calling itself historical. <code>0d124bf1</code>, &quot;feat: add Zipp landing page&quot;, is the first version of this site.</p>]]></content:encoded>
</item>
<item>
<title>PGO adopted at −13.3%</title>
<link>https://www.zipp.org/journal/pgo-adopted/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/pgo-adopted/</guid>
<pubDate>Mon, 03 Aug 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<category>build</category>
<description>Profile-guided optimization takes the headline from 1.749× to 1.451× Node in one build change; two more waves the same day reach 1.330×.</description>
<content:encoded><![CDATA[<p>Profile-guided optimization takes the headline from 1.749× to 1.451× Node in one build change; two more waves the same day reach 1.330×.</p>
<p><code>5cafcb10</code>. Every capture since has been a PGO build with the profile&#39;s hash, the recipe, the compiler, the linker and the source snapshot all recorded in the artifact; the working rule is &quot;PGO retrain before any headline capture&quot; and &quot;never promote a dirty, filtered, non-PGO, or incomplete-engine artifact&quot;.</p>]]></content:encoded>
</item>
<item>
<title>The first capture the repository can attribute to a commit</title>
<link>https://www.zipp.org/journal/first-attributable-capture/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/first-attributable-capture/</guid>
<pubDate>Sat, 01 Aug 2026 00:00:00 GMT</pubDate>
<category>performance</category>
<category>methodology</category>
<description>Benchmark artifacts begin recording engine commit, dirty flag, competitor hashes and per-repetition schedules, after a harness was found able to name a commit it had never measured.</description>
<content:encoded><![CDATA[<p>Benchmark artifacts begin recording engine commit, dirty flag, competitor hashes and per-repetition schedules, after a harness was found able to name a commit it had never measured.</p>
<p><code>f1b38086</code>: &quot;bench: the first capture this repo can attribute to a commit&quot;. The sampling profiler the roadmap had wanted since its third ticket landed the day before. The ledger&#39;s measurement-hygiene section records the failures that motivated this: a profiler &quot;lying about a quarter of json-large&quot;, a harness that &quot;could name a commit it had never measured&quot;, and a leftover <code>ZIPP_GC_STRESS=1</code> process from a killed session that held a core for hours and was misdiagnosed as an engine livelock.</p>]]></content:encoded>
</item>
<item>
<title>A new home at github.com/f2i-com/zipp.org</title>
<link>https://www.zipp.org/journal/a-new-home/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/a-new-home/</guid>
<pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
<category>site</category>
<category>conformance</category>
<description>The README points at the repository&#39;s permanent address; the day before, the corpus refresh had left Test262 at 95,939 of 95,942.</description>
<content:encoded><![CDATA[<p>The README points at the repository&#39;s permanent address; the day before, the corpus refresh had left Test262 at 95,939 of 95,942.</p>
<p><code>94e7e0f5</code> moves the README to the new home. <code>d5d0ae7b</code> (29 July) refreshed the corpus and implemented <code>Iterator.prototype.join</code>, 36 executions that V8 24.12 does not pass either: &quot;the suite is the oracle, not node&quot;. <code>799ead6d</code> recorded the last full-suite Intl402 figure on record, 6,502 of 6,714.</p>]]></content:encoded>
</item>
<item>
<title>30 failures to 5, and 22 of the 30 were runner defects</title>
<link>https://www.zipp.org/journal/thirty-failures-to-five/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/thirty-failures-to-five/</guid>
<pubDate>Wed, 29 Jul 2026 00:00:00 GMT</pubDate>
<category>conformance</category>
<description>Two phantom executions removed, then 22 of 30 remaining failures traced to the repository or runner rather than the engine; 99.995% on 95,846 executions.</description>
<content:encoded><![CDATA[<p>Two phantom executions removed, then 22 of 30 remaining failures traced to the repository or runner rather than the engine; 99.995% on 95,846 executions.</p>
<p><code>a3d616d3</code> reaches 99.97% with 30 failures and claims Annex B handling &quot;more conformant than Node&quot;, a claim later retracted. <code>d0854919</code>: &quot;test262: 30 -&gt; 5, and none of the 5 is a live engine defect&quot;. Of the five, module-level <code>using</code> declarations that were never disposed accounted for six executions fixed the same day, and the mutually exclusive Annex B pair (&quot;95,942/95,942 does not exist for any engine — V8 fails the same one&quot;) became the standing caveat.</p>]]></content:encoded>
</item>
<item>
<title>Intl.DurationFormat, the IANA time-zone database, and the Test262 tail</title>
<link>https://www.zipp.org/journal/intl-durationformat-and-the-time-zone-database/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/intl-durationformat-and-the-time-zone-database/</guid>
<pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
<category>conformance</category>
<category>intl</category>
<description>Non-ISO Temporal calendars take Intl402 from 63.6% to 96.9% in a day; the core suite reaches 99.91%.</description>
<content:encoded><![CDATA[<p>Non-ISO Temporal calendars take Intl402 from 63.6% to 96.9% in a day; the core suite reaches 99.91%.</p>
<p>Four commits in one day: <code>b550a4ca</code> adds <code>Intl.DurationFormat</code> and the IANA database generated from pinned upstream data; <code>04edd833</code> adds non-ISO Temporal calendars (Intl402 63.6% → 85.3%); <code>1ae58724</code> reaches 99.88% core and 96.9% Intl402; <code>f1997ad8</code> reaches 99.91%. Temporal ended up with fifteen calendars: twelve closed-form, Chinese and Dangi by astronomical calculation, and Umm al-Qura from the required month data.</p>]]></content:encoded>
</item>
<item>
<title>99.0%, a new in-house front end, and an honest denominator change</title>
<link>https://www.zipp.org/journal/ninety-nine-percent-and-a-new-front-end/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/ninety-nine-percent-and-a-new-front-end/</guid>
<pubDate>Mon, 27 Jul 2026 00:00:00 GMT</pubDate>
<category>conformance</category>
<category>parser</category>
<description>A new front end cuts parse-negative failures from 607 files to 80; honouring YAML list-form flags drops the denominator by 181 executions and the score is republished.</description>
<content:encoded><![CDATA[<p>A new front end cuts parse-negative failures from 607 files to 80; honouring YAML list-form flags drops the denominator by 181 executions and the score is republished.</p>
<p><code>6fc39171</code> (98.1%) is the new front end built for correct early errors. <code>321c328b</code> reaches 99.0% (95,091 of 96,029). <code>8cec7647</code> then honours YAML list-form <code>flags:</code> metadata, which removes 181 phantom executions and changes the denominator to 95,848; the number was republished as 99.2% rather than left inflated.</p>]]></content:encoded>
</item>
<item>
<title>zipp-wasm: a persistent VM for browser hosts, and fat LTO</title>
<link>https://www.zipp.org/journal/zipp-wasm-persistent-vm/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/zipp-wasm-persistent-vm/</guid>
<pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
<category>wasm</category>
<category>build</category>
<category>conformance</category>
<description>The WebAssembly embedding lands as a persistent VM that compiles once and re-enters later; fat LTO with one codegen unit buys about 2%; regex literals validated at compile time add 712 executions.</description>
<content:encoded><![CDATA[<p>The WebAssembly embedding lands as a persistent VM that compiles once and re-enters later; fat LTO with one codegen unit buys about 2%; regex literals validated at compile time add 712 executions.</p>
<p><code>f6f4a804</code> adds <code>zipp-wasm</code>; <code>768287f8</code> adds the persistent-VM embedding API, &quot;compile once, re-enter later&quot;, which is the model the browser <code>Engine</code> class still follows. <code>694886b8</code> turns on fat LTO and <code>codegen-units = 1</code> (2.80× → 2.77×, &quot;free&quot;). <code>44c4c738</code> validates regular-expression literals at compile time, the single largest conformance jump of the week at +712 executions.</p>]]></content:encoded>
</item>
<item>
<title>The reckoning: 96.97%, not 100%</title>
<link>https://www.zipp.org/journal/the-reckoning/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/the-reckoning/</guid>
<pubDate>Sat, 25 Jul 2026 00:00:00 GMT</pubDate>
<category>conformance</category>
<category>methodology</category>
<description>After six silent weeks, the Test262 runner is found to have been scoring a single execution mode; the honest pass rate is 96.97%. The same day, every crate but zipp-vm is deleted and the docs are rewritten against measurements.</description>
<content:encoded><![CDATA[<p>After six silent weeks, the Test262 runner is found to have been scoring a single execution mode; the honest pass rate is 96.97%. The same day, every crate but zipp-vm is deleted and the docs are rewritten against measurements.</p>
<p><code>1217d683</code>: &quot;Fix the test262 runner; real pass rate is 96.97%, not 100%&quot;. The runner had reported 48,550 passes of 48,556 single-mode executions; the corpus required 96,029. <code>9ef187f9</code>: &quot;Focus the workspace on zipp-vm; rewrite the docs against measurements&quot;, deleting the AOT, Cranelift, LLVM, zero-knowledge and TypeScript crates from May. <code>b865f9c6</code> adopts <code>mimalloc</code> as the global allocator, 4.20× → 3.34× Node on the honest suite. The roadmap&#39;s B10 entry the same day is &quot;the measured backlog from the 25-agent speed hunt&quot;.</p>]]></content:encoded>
</item>
<item>
<title>Tier C function JIT on by default, and a checkable roadmap</title>
<link>https://www.zipp.org/journal/function-jit-on-by-default-and-the-roadmap/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/function-jit-on-by-default-and-the-roadmap/</guid>
<pubDate>Sun, 14 Jun 2026 00:00:00 GMT</pubDate>
<category>jit</category>
<category>performance</category>
<description>The whole-function JIT tier is enabled by default (parse 4.1× → 3.3× Node) and PERF_ROADMAP.md is written as a checkable path to V8 parity. Then the log goes quiet for six weeks.</description>
<content:encoded><![CDATA[<p>The whole-function JIT tier is enabled by default (parse 4.1× → 3.3× Node) and PERF_ROADMAP.md is written as a checkable path to V8 parity. Then the log goes quiet for six weeks.</p>
<p><code>4e12a406</code> and <code>f0d725a8</code> enable the Tier C function-level JIT by default. <code>62dbba15</code> adds <code>PERF_ROADMAP.md</code>, whose tickets (B1, B2, B3…) number every later performance commit. The day before, <code>7e29d967</code> had fixed six JIT soundness bugs found by an adversarial audit of the session&#39;s own codegen. June ends with 1,039 commits.</p>]]></content:encoded>
</item>
<item>
<title>WTF-8 strings, big BigInt, and the honest benchmark pack</title>
<link>https://www.zipp.org/journal/wtf-8-bigint-and-the-honest-pack/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/wtf-8-bigint-and-the-honest-pack/</guid>
<pubDate>Fri, 12 Jun 2026 00:00:00 GMT</pubDate>
<category>language</category>
<category>performance</category>
<description>Strings gain real lone-surrogate support, BigInt gains a two-tier i128 plus num-bigint implementation, and bench/real arrives as a ten-workload five-engine suite.</description>
<content:encoded><![CDATA[<p>Strings gain real lone-surrogate support, BigInt gains a two-tier i128 plus num-bigint implementation, and bench/real arrives as a ten-workload five-engine suite.</p>
<p><code>c43b17ce</code>: WTF-8 so that a lone surrogate survives a round trip, as ECMAScript requires. <code>7f4e58b6</code>: BigInt with an <code>i128</code> fast tier backed by <code>num-bigint</code>. <code>f00c2010</code>: &quot;Add bench/real: ten-workload five-engine suite (the honest pack)&quot;, the ancestor of today&#39;s real13 suite. The day before, <code>b2c04ace</code> had given <code>Atomics</code> a real blocking wait with a global FIFO waiter registry and cross-thread notify, and <code>247238ca</code> had added proper tail calls.</p>]]></content:encoded>
</item>
<item>
<title>ES modules with top-level await</title>
<link>https://www.zipp.org/journal/es-modules-with-top-level-await/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/es-modules-with-top-level-await/</guid>
<pubDate>Mon, 08 Jun 2026 00:00:00 GMT</pubDate>
<category>language</category>
<category>conformance</category>
<description>Module mode lands with top-level await and a Test262 module runner; modules become runtime structures on the explicit frame stack like everything else.</description>
<content:encoded><![CDATA[<p>Module mode lands with top-level await and a Test262 module runner; modules become runtime structures on the explicit frame stack like everything else.</p>
<p><code>5fba4d7d</code>: &quot;Run ES modules: top-level-await module mode + test262 module runner&quot;. The module graph, <code>[[CycleRoot]]</code>, deferred evaluation ordering and errored-cycle re-import would each get their own fix over the following three months; today&#39;s <code>zipp mjs</code> is the descendant of this commit.</p>]]></content:encoded>
</item>
<item>
<title>eval, the number-one conformance lever, and ShadowRealm</title>
<link>https://www.zipp.org/journal/eval-and-shadowrealm/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/eval-and-shadowrealm/</guid>
<pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate>
<category>language</category>
<category>conformance</category>
<description>Indirect and global-scope eval land, followed by ShadowRealm, both as runtime structures rather than native recursion.</description>
<content:encoded><![CDATA[<p>Indirect and global-scope eval land, followed by ShadowRealm, both as runtime structures rather than native recursion.</p>
<p><code>76169428</code>: &quot;implement eval (indirect / global-scope) — the #1 conformance lever&quot;. <code>97e07a67</code> adds <code>ShadowRealm</code>. Both are cheap in an explicit-frame VM: a new realm is a new set of intrinsics and a new global, not a new native stack.</p>]]></content:encoded>
</item>
<item>
<title>RegExp, TypedArrays, Proxy, Temporal and Intl in one day</title>
<link>https://www.zipp.org/journal/regexp-typedarrays-proxy-temporal-intl/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/regexp-typedarrays-proxy-temporal-intl/</guid>
<pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
<category>language</category>
<category>conformance</category>
<category>gc</category>
<description>A forked regress engine for regular expressions, eleven TypedArray constructors, Proxy traps, Temporal type by type, the whole Intl namespace, a mark-sweep GC, and a 17,400-line vm.rs split into a folder.</description>
<content:encoded><![CDATA[<p>A forked regress engine for regular expressions, eleven TypedArray constructors, Proxy traps, Temporal type by type, the whole Intl namespace, a mark-sweep GC, and a 17,400-line vm.rs split into a folder.</p>
<p>The busiest day in the log. <code>8520b6a8</code> wires regular expressions through the <code>regress</code> crate (later forked for UTF-16 execution and a regex JIT). <code>65e33aed</code>: <code>ArrayBuffer</code> and eleven TypedArray constructors. <code>48633f27</code>: Proxy traps. <code>4a3f85b6</code> through <code>00df2adc</code>: Temporal, from <code>Duration</code> to <code>PlainDate</code> to <code>Instant</code> to <code>Now</code>. <code>ebf7dca3</code>: &quot;implement the Intl namespace + all 11 services (0 -&gt; ~340 tests)&quot;. <code>a9b1d901</code>: &quot;split the 17.4k-line vm.rs into a vm/ module folder&quot;. <code>b5d691e1</code>: a mark-sweep collector for the new VM.</p>]]></content:encoded>
</item>
<item>
<title>A Test262 runner, and async generators as the biggest lever</title>
<link>https://www.zipp.org/journal/test262-runner-and-async-generators/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/test262-runner-and-async-generators/</guid>
<pubDate>Mon, 01 Jun 2026 00:00:00 GMT</pubDate>
<category>conformance</category>
<category>language</category>
<description>The conformance runner lands one day after the pivot, and async generators are implemented as the largest single block of failing executions.</description>
<content:encoded><![CDATA[<p>The conformance runner lands one day after the pivot, and async generators are implemented as the largest single block of failing executions.</p>
<p><code>79d10480</code>: &quot;tools: add test262 conformance runner&quot;. <code>dd820da7</code>: &quot;async generators (async function*) — the biggest conformance lever&quot;. From this day on, features were measured in executions passed, though it would take until 25 July for the runner to count them correctly.</p>]]></content:encoded>
</item>
<item>
<title>First native JIT, inline caches, ropes, and a first win over V8</title>
<link>https://www.zipp.org/journal/first-native-jit-and-first-win-over-v8/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/first-native-jit-and-first-win-over-v8/</guid>
<pubDate>Sun, 31 May 2026 00:00:00 GMT</pubDate>
<category>jit</category>
<category>performance</category>
<description>The register VM gets an x86-64 JIT for hot integer functions, OSR loop regions, call-free inline caches, scalar replacement, rope strings and a microtask loop, and beats V8 on loop.js at 26.5 ms against 28.0.</description>
<content:encoded><![CDATA[<p>The register VM gets an x86-64 JIT for hot integer functions, OSR loop regions, call-free inline caches, scalar replacement, rope strings and a microtask loop, and beats V8 on loop.js at 26.5 ms against 28.0.</p>
<p>In one day: <code>59032ebd</code> &quot;native x86-64 JIT for hot integer functions (4.1x where it fires)&quot;; <code>b882eea5</code> &quot;OSR loop-region JIT (double/SSE2)&quot;; <code>050fe88d</code> &quot;call-free inline cache for GetProp/SetProp — object.js 14ms → 3ms&quot;; <code>bca59c77</code> scalar replacement, &quot;object 31ms → 8ms&quot;; <code>e6e63a0a</code> &quot;rope strings + cached length/index — kill the O(n²) in string concat &amp; scan&quot;; <code>0db0d5af</code> &quot;Remove the old JS engines; <code>zipp js</code> now runs zipp-vm&quot;; <code>a5cf5a3e</code> promises and a microtask event loop; and <code>d7d9d5e0</code>, &quot;cheap 2^53 guard (range trick) — BEAT V8 on loop.js (26.5 vs 28.0ms)&quot;.</p>]]></content:encoded>
</item>
<item>
<title>The pivot to JavaScript, and the register VM that stuck</title>
<link>https://www.zipp.org/journal/the-pivot-to-javascript/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/the-pivot-to-javascript/</guid>
<pubDate>Sat, 30 May 2026 00:00:00 GMT</pubDate>
<category>vm</category>
<category>methodology</category>
<description>The ES5 object model arrives, a bytecode compiler and VM are built, two engines are tried, and by evening the clean-sheet explicit-frame register VM exists. So does the first retraction of a false performance claim.</description>
<content:encoded><![CDATA[<p>The ES5 object model arrives, a bytecode compiler and VM are built, two engines are tried, and by evening the clean-sheet explicit-frame register VM exists. So does the first retraction of a false performance claim.</p>
<p><code>262ae969</code>: &quot;prototypes, <code>new</code>, <code>instanceof</code>, <code>in</code> (the ES5 object model)&quot;. <code>e2440724</code> wires <code>zipp js &lt;file.js&gt;</code>. A fuzzer campaign follows, fixing <code>Number::toString</code> and bugs numbered 1 through 32 one commit at a time. <code>ecc96a94</code> is the first bytecode compiler and VM; <code>4c826c54</code> absorbs an earlier engine and rebrands it; <code>50634ccd</code> is &quot;FIX broken build + RETRACT the false perf claims in 4c826c5&quot;. Then <code>87174f64</code>: &quot;zipp-vm: clean-sheet JS engine v2 — explicit-frame register VM&quot;, the design every later page on this site describes.</p>]]></content:encoded>
</item>
<item>
<title>Day one: ZIPP language v0, with four back ends before midnight</title>
<link>https://www.zipp.org/journal/day-one/</link>
<guid isPermaLink="true">https://www.zipp.org/journal/day-one/</guid>
<pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
<category>origins</category>
<description>The initial commit is a tree-walking interpreter for a small typed language; by the end of the day it has a Cranelift JIT, an LLVM tier, a mark-sweep GC, a gas-metered WebAssembly profile, a zero-knowledge back end and a TypeScript front end.</description>
<content:encoded><![CDATA[<p>The initial commit is a tree-walking interpreter for a small typed language; by the end of the day it has a Cranelift JIT, an LLVM tier, a mark-sweep GC, a gas-metered WebAssembly profile, a zero-knowledge back end and a TypeScript front end.</p>
<p><code>a71a1bdc</code>, &quot;Initial commit - ZIPP language v0&quot;, 13:38 on 29 May 2026. <code>d0fe82fa</code>: &quot;Add native JIT (Cranelift) for the integer subset — beats V8 on a hot loop&quot;. <code>c30bb934</code>: &quot;Add LLVM release tier (clang -O3) — matches V8 on dense f64&quot;. <code>924ed4a1</code>: a conservative mark-sweep GC. <code>fe045b2b</code>: &quot;the WASM contract profile: deterministic, gas-metered WebAssembly&quot;. <code>b1847a67</code>: &quot;zk hardening: bind proofs to a program hash&quot;. <code>5d1c1fab</code>: a TypeScript front end via <code>oxc</code>. All of it was deleted on 25 July; the habit of naming the measurement in the commit subject survived.</p>]]></content:encoded>
</item>
</channel>
</rss>
