WAH: Ein WebAssembly-Interpreter in nur einer Header-Datei

 (github.com/lifthrasiir)
2 Punkte von lifthrasiir 20 일 전 | 2 Kommentare | Auf WhatsApp teilen

Ich habe nach längerer Zeit mal wieder eine C-Bibliothek gebaut. Es ist, wortwörtlich, ein WebAssembly-Interpreter, bei dem alles in einer einzigen C-Header-Datei steckt. Natürlich ist es nicht nur einfach ein nackter Interpreter, sondern:

  • unterstützt die WebAssembly-3.0-Spezifikation zu 100 %. Ja, inklusive GC und all dem anderen Kram.
  • implementiert das sogenannte deterministic profile von WebAssembly, eine Option, die dafür sorgt, dass in jeder Umgebung dieselben Ergebnisse herauskommen. Daher ist es nützlich für reproduzierbare Resultate.
  • enthält architekturspezifische Optimierungen für x86-64 und AArch64 NEON.
  • enthält die Funktionen, die man zum Sandboxing von nicht vertrauenswürdigem Code braucht. Unterstützt werden etwa Fuel Metering, bei dem bei der Ausführung von Befehlen „Fuel“ verbraucht wird und die Ausführung stoppt, wenn es aufgebraucht ist, außerdem Interrupts nach einer bestimmten Laufzeit sowie die Kontrolle des Speicherverbrauchs.
  • die API ist so gestaltet, dass die Ausführung auch dann wieder aufgenommen werden kann, wenn sie währenddessen angehalten wurde.
  • WebAssembly-Module können rein per Code erzeugt werden, und mehrere Module lassen sich in ein einzelnes Modul linken.
  • Funktionen lassen sich sowohl zur Compile-Zeit einschränken (wodurch weniger Code kompiliert wird) als auch zur Laufzeit.
  • wurde von Anfang an mit dem Ziel entworfen, ein festes ABI zu haben. Datenstrukturen können auf dem C-Stack alloziert werden, aber ihr Layout ist vorab fixiert, sodass auch bei neuen Versionen die ABI-Kompatibilität nicht bricht.
  • darüber hinaus gibt es geradezu übertrieben viele Tests, und es wurde intensiv Fuzz-Testing betrieben. (Tatsächlich läuft der Fuzzer sogar jetzt noch …)

Ursprünglich sollte das nur ein Teil eines anderen Projekts werden, deshalb hatte ich gar nicht vor, es so kompromisslos umzusetzen. Aber um die Tests der WebAssembly-Referenzimplementierung auszuführen (sie heißen spectest), musste am Ende eben doch alles implementiert werden … und so ist es irgendwie zu einer 100-%-Implementierung geworden. Wie ist es bloß dazu gekommen?

Dem aktuellen Trend folgend wurde der Code anfangs mit Gemini CLI geschrieben, ab der Mitte dann mit Claude Code und gelegentlich mit Codex; für die Planung kam vor allem Codex zum Einsatz. Für mich war das persönlich auch ein Projekt, das zeigen sollte, dass Coding Agents mit genügend gutem Steering selbst hardcore Systemprogrammierung ziemlich gut hinbekommen können. Ich wollte auch ein Gegenbeispiel zu der Einschätzung liefern, dass beim Vibe Coding zwar irgendetwas Plausibles herauskommt, die Details aber am Ende chaotisch sind.

Verwandte Beiträge

2 Kommentare

 
ipeng 20 일 전

Wenn die zu testende Spezifikation klar ist, scheint der Ansatz gut zu funktionieren, mit einem Coding-Agenten einen Workflow zu entwerfen und ihn zur Konvergenz zu bringen. Dabei fallen mir auch Beispiele wie vinext und pretext ein.

Anderes Thema, aber könntet ihr vielleicht einmal prüfen, ob im Journal das CSS ausgeliefert wird ...? Obwohl schon einige Zeit vergangen ist, gibt es immer noch viele gute Artikel, die ich gern Leuten in meinem Umfeld empfehlen würde, aber beim Zugriff über den Desktop wird das CSS nicht geladen ;_;
 
lifthrasiir 20 일 전

Der Server, der das CSS ausgeliefert hat, ist abgestürzt schluchz schluchz Entschuldigung, aber bitte nutzt vorerst die Wayback Machine...