WAH : un interpréteur WebAssembly conçu dans un seul fichier d’en-tête
(github.com/lifthrasiir)Cela faisait longtemps que je n’avais pas créé de bibliothèque C. Comme son nom l’indique, il s’agit d’un interpréteur WebAssembly dont tout tient dans un unique fichier d’en-tête C. Bien sûr, il ne s’agit pas seulement d’un interpréteur minimaliste :
- Il prend en charge à 100 % la spécification WebAssembly 3.0. Oui, y compris le GC et tout le reste.
- WebAssembly propose une option appelée profil déterministe (
deterministic profile) pour garantir le même résultat dans n’importe quel environnement, et cette option est implémentée. C’est donc utile pour obtenir des résultats reproductibles. - Des optimisations spécifiques à l’architecture sont appliquées pour x86-64 et AArch64 NEON.
- Il intègre les fonctionnalités nécessaires pour sandboxer du code non fiable. Sont prises en charge des fonctions comme le fuel metering, qui exécute les instructions en consommant du « carburant » (
fuel) puis s’arrête lorsque celui-ci est épuisé, ainsi que la possibilité d’interrompre l’exécution après un certain délai ou de contrôler l’utilisation mémoire. - L’API est conçue pour permettre de reprendre l’exécution même après un arrêt en cours de route.
- Il est possible de générer des modules WebAssembly uniquement par le code, ou de lier plusieurs modules dans un seul.
- Les fonctionnalités peuvent être restreintes à la compilation (ce qui réduit le code compilé) comme à l’exécution.
- Le projet a été conçu dès le départ avec l’objectif de figer l’ABI. Les structures de données peuvent être allouées sur la pile C, mais leur layout est fixé à l’avance afin que l’ABI ne soit pas cassée même si la version évolue.
- En plus de cela, il y a une quantité presque excessive de tests, et le fuzz testing a été poussé très loin. (En fait, le fuzzer tourne encore en ce moment même...)
Au départ, cela devait faire partie d’un autre projet, donc je n’avais pas prévu d’aller aussi loin. Mais pour exécuter les tests de l’implémentation de référence WebAssembly (appelés spectest), il a finalement fallu tout implémenter... Et c’est ainsi que j’en suis arrivé à une implémentation à 100 %. Comment est-ce qu’on en est arrivé là ?
Dans l’air du temps, le code a d’abord été écrit avec Gemini CLI, puis surtout avec Claude Code et parfois Codex à partir du milieu du projet, tandis que la planification s’est principalement appuyée sur Codex. Personnellement, c’était aussi un projet qui démontrait qu’avec un bon pilotage, les agents de code peuvent très bien s’en sortir même sur de la programmation système hardcore. J’avais aussi envie d’en faire un contre-exemple à l’idée selon laquelle le vibe coding produit certes quelque chose d’apparemment plausible, mais de bancal dans les détails.
2 commentaires
J’ai l’impression que quand les spécifications à tester sont claires, une approche qui consiste à concevoir un workflow avec un agent de code pour le faire converger fonctionne plutôt bien. Ça me fait penser à des cas comme vinext ou pretext.
Autre sujet, est-ce que vous pourriez vérifier une fois le service CSS du journal, par hasard… ? Même après tout ce temps, il y a beaucoup de très bons articles que j’aimerais recommander autour de moi, mais en y accédant depuis un ordinateur, le CSS ne se charge pas, snif snif
Le serveur qui servait le CSS est mort T_T Désolé, mais pour le moment merci d’utiliser la Wayback Machine...