🔨 J'ai créé un compilateur C en PHP capable de compiler du SQLite

le 30 août 2026

Je voulais savoir quelle part du compilateur C je pouvais implémenter en PHP avant qu'il ne soit capable de compiler SQLite.

À l'heure actuelle, la réponse est : suffisant. Sur macOS ARM64, une interface C hébergée par PHP et un générateur de code ARM64 transforment le code SQLite 3.46.0 en assembleur textuel. L'assembleur et l'éditeur de liens d'Apple génèrent ensuite un exécutable natif. Un petit programme ouvre une base de données en mémoire, y insère une ligne, la sélectionne et l'affiche.

darkwood

Ce test d'acceptation est complété par une suite de tests de régression qui réussit 46/46 tests. Le pipeline de compilation/validation externe est orchestré avec darkwood/flow v8.1.5.

Cet article propose une visite guidée de cette implémentation : comment le code source devient des jetons, comment les macros s’étendent, comment les déclarateurs deviennent des types, comment l’analyse sémantique alimente la génération de code, comment l’architecture ARM64 est générée et quels bogues ont contraint les abstractions à adopter une approche pragmatique. Le plus intéressant n’est pas un tableau de bord de performances, mais le PHP qui implémente le C.

Que signifie concrètement « compiler SQLite en PHP » ?

La précision est importante, car il est facile de survendre cette expression.

Le compilateur PHP implémente :

C source
  → lexer / preprocessor
  → parser
  → AST
  → semantic analysis
  → ARM64 code generation
  → .s assembly text

Les outils natifs d'Apple effectuent ensuite les opérations suivantes :

ARM64 .s
  → Apple assembler (as)
  → Mach-O object

objects
  → system linker via the clang driver
  → native executable

Clang n'est pas utilisé pour compiler sqlite3.c dans le chemin d'acceptation. Il est utilisé comme pilote de liaison et parfois comme oracle différentiel pour les petites requêtes. PHP n'écrit pas de code Mach-O. La limite intéressante est :

PHP implémente l'interface C et le générateur de code ARM64 ; l'assembleur et l'éditeur de liens de la plateforme finalisent l'exécutable natif.

L'architecture délibérément réduite

Il n'y a ni CIR, ni formulaire SSA, ni pipeline d'optimisation. Le pilote dans src/Compiler/Driver/Compiler.php est presque linéaire :

$preprocessor = new Preprocessor($this->sourceManager, $options->includePaths, $options->defines);
$tokens = $preprocessor->preprocess($fileId);

$parser = new Parser($tokens, $this->diagnostics);
$decls = $parser->parse();
unset($parser, $tokens);

$sema = new Sema($this->diagnostics);
$tast = $sema->analyze($decls);
$enumConstants = $sema->enumConstants;
unset($sema);

$codegen = new Codegen($enumConstants);
$assembly = $codegen->generate($tast);

Symfony prend en charge les commandes de la console (app:compiler-check, app:compiler-fixtures, app:compiler-sqlite, etc.). Elles ne font pas partie de l'algorithme de compilation. Le code pertinent se trouve dans src/Compiler/, sous forme de classes PHP classiques. Les fichiers d'en-tête sous include/ fournissent une interface minimale Darwin/libc pour le frontend — suffisante pour stdio, stdlib, les threads et les déclarations associées — sans nécessiter une réécriture complète du SDK.

L'utilisation de l'assembleur textuel était un choix de portée. Générer un fichier .s permet d'hériter des diagnostics de l'assembleur d'Apple et d'un chemin de débogage lisible, sans avoir à créer un générateur Mach-O en PHP.

En image :

                     PHP

sqlite3.c
   │
   ▼
┌──────────────┐
│ Preprocessor │
└──────┬───────┘
       ▼
┌──────────────┐
│    Parser    │
└──────┬───────┘
       ▼
┌──────────────┐
│     AST      │
└──────┬───────┘
       ▼
┌──────────────┐
│     Sema     │
└──────┬───────┘
       ▼
┌──────────────┐
│ ARM64 Codegen│
└──────┬───────┘
       │
       ▼
    sqlite3.s

                  macOS toolchain

sqlite3.s → as → sqlite3.o
smoke.s  → as → smoke.o
                 │
                 ▼
              linker → executable → darkwood

Fichiers sources et jetons

La compilation commence par l'identification de la source, et non par la grammaire.

SourceLoc est volontairement très petit : un identifiant de fichier et un décalage en octets.

// src/Compiler/Common/SourceLoc.php
final readonly class SourceLoc
{
  public function __construct(
    public int $fileId,
    public int $offset,
  ) {
  }
}

La ligne et la colonne sont calculées ultérieurement par SourceManager::lineCol(). Le gestionnaire conserve le contenu du fichier et une table en cache des décalages de début de ligne, puis effectue une recherche dichotomique pour trouver le décalage de début le plus grand <= offset :

// src/Compiler/Common/SourceManager.php (excerpt)
$starts = $this->lineStarts($loc->fileId);
// Binary search: largest line-start index with start <= offset.
$lo = 0;
$hi = count($starts) - 1;
while ($lo <= $hi) {
  $mid = intdiv($lo + $hi, 2);
  if ($starts[$mid] <= $offset) {
    $lo = $mid + 1;
  } else {
    $hi = $mid - 1;
  }
}
$lineIdx = max(0, $hi);
$lineStart = $starts[$lineIdx];

return ['line' => $lineIdx + 1, 'col' => $offset - $lineStart + 1];

Les jetons contiennent l'orthographe, le type, l'emplacement et — élément crucial pour le préprocesseur — un ensemble de masquage :

// src/Compiler/Common/Token.php
final readonly class Token
{
  /**
   * @param list<string> $hideSet Names that should NOT be expanded for this token (blue-painting)
   */
  public function __construct(
    public TokenKind $kind,
    public string $spelling,
    public SourceLoc $loc,
    public array $hideSet = [],
  ) {
  }

  public function withHideSet(array $newHideSet): self
  {
    // ...
    return new self(
      kind: $this->kind,
      spelling: $this->spelling,
      loc: $this->loc,
      hideSet: $newHideSet,
    );
  }
}

TokenKind est une petite énumération : identifiant, mot-clé, littéraux entiers/flottants/caractères/chaînes de caractères, ponctuation et EOF. La conservation de l’emplacement de chaque jeton permet d’établir des diagnostics de la forme file.c:line:column: error: ... après l’échec des étapes ultérieures.

Il s'agit également d'une structure typiquement PHP : objets de valeur immuables, tableaux de jetons et répartition instanceof/match plus tard dans le pipeline.

Création d'un préprocesseur C en PHP

Le préprocesseur n'effectue pas de substitution de chaînes de caractères. Il s'agit d'une machine à jetons avec compilation conditionnelle et expansion récursive de macros.

La fonction Preprocessor::processTokens() parcourt un flux de jetons indexé. Une pile de conditions suit les directives #if / #elif / #else / #endif avec des cadres de la forme {parentActive, anyBranchTaken, currentActive, seenElse}. Les jetons ne sont intégrés au chemin d'expansion que lorsque tous les cadres sont actifs. Les régions inactives continuent d'analyser les directives, ce qui permet de maintenir l'équilibre de l'imbrication.

Lorsque la région est active, les jetons non directifs sont regroupés jusqu'au prochain début de ligne #, puis transmis à MacroExpander::expand() :

// src/Compiler/Preproc/Preprocessor.php (excerpt)
if ($isActive()) {
  $batch = [];
  while ($i < count($tokens)) {
    $t = $tokens[$i];
    if ($t->kind === TokenKind::Punct && $t->spelling === '#'
        && $this->isAtLineStart($output, $tokens, $i)) {
      break;
    }
    $batch[] = $t;
    ++$i;
  }
  if ($batch !== []) {
    array_push($output, ...$this->expander->expand($batch));
  }
  continue;
}

Les expressions #if sont développées par le même expandeur après la réécriture defined(...), puis évaluées comme des expressions constantes.

Ensembles d'expansion et de masquage de macros

MacroExpander (dans MacroTable.php) utilise un curseur indexé sur l'entrée d'origine, ainsi qu'une pile d'attente inversée pour la réanalyse. Les expansions sont effectuées en sens inverse, de sorte que le prochain jeton à traiter est le premier jeton de l'expansion — une sémantique de réanalyse classique sans avoir à effectuer des appels répétés à array_shift() sur une grande liste.

Lorsqu'un identifiant désigne une macro et n'est pas désactivé par son ensemble de masquage, l'extenseur fusionne le nom de la macro avec l'ensemble de masquage des jetons de remplacement (« peinture bleue »). Cela empêche une récursion infinie lorsqu'une macro se développe en son propre nom :

// src/Compiler/Preproc/MacroTable.php (excerpt)
if ($token->hideSet !== [] && in_array($token->spelling, $token->hideSet, true)) {
  $output[] = $token;
  continue;
}

$macro = $this->table->lookup($token->spelling);
// ...
$newHideSet = $this->unionHideSet($token->hideSet, [$macro->name]);
$expanded = $this->expandObjectLike($macro, $token->loc, $newHideSet);
for ($i = count($expanded) - 1; $i >= 0; --$i) {
  $pendingReversed[] = $expanded[$i];
}

Les macros de type fonction analysent les listes d'arguments, prennent en charge la conversion en chaîne de caractères avec # et le collage avec ##, et appliquent des ensembles de masquage aux jetons du corps. Les macros de type objet sont une version simplifiée de ce même mécanisme.

La substitution parcourt le corps de la macro jeton par jeton. Les noms des paramètres sont remplacés par les listes de jetons d'arguments correspondantes (elles-mêmes soumises aux règles d'expansion), # convertit un argument en une chaîne littérale, et ## concatène les jetons adjacents pour former une nouvelle orthographe. __VA_ARGS__ intervient pour les macros de type fonction variadique. Chaque jeton produit possède un ensemble de masquage incluant la macro en cours d'expansion, de sorte qu'une analyse ultérieure n'entrera pas à nouveau le même nom via le même jeton coloré.

Pour un lecteur technique : il s’agit d’un véritable sous-système de préprocesseur. L’agrégation de SQLite repose fortement sur les macros ; sans les ensembles masqués, la collecte des arguments, la conversion en chaîne de caractères et la compilation conditionnelle, l’analyseur syntaxique ne pourrait jamais obtenir un flux de jetons cohérent.

Un des premiers tests de régression, 011-macro-eof, encode un cas limite où l'interaction de la fin de fichier (EOF) avec le remplacement de macros et l'évaluation conditionnelle corrompt le prétraitement. Ce type de test est une pratique courante du projet : réduire l'erreur de fusion à un minuscule programme qui plante toujours en cas de régression du préprocesseur. Un autre test, 012-octal-escape, intervient une étape plus tard dans l'analyseur lexical/décodeur de chaînes — "\040" doit être converti en octet correct — mais il illustre le même principe : les règles lexicales « ennuyeuses » du C deviennent essentielles dès l'apparition des véritables en-têtes.

Analyse syntaxique du C sans générateur d'analyseur syntaxique

L'analyseur syntaxique est un hybride récursif descendant/Pratt écrit à la main, appliqué au tableau de jetons. Il n'utilise pas la grammaire yacc. Les déclarations, instructions et expressions sont des méthodes de Parser.

Les nœuds AST sont des classes PHP ordinaires situées dans src/Compiler/Common/Ast.php. Exemples de formes :

final class FuncDecl extends Decl
{
    public function __construct(
        public string $name,
        public CType $returnType,
        public array $params,
        public bool $variadic,
        SourceLoc $loc,
        public ?CompoundStmt $body = null,
        public StorageClass $storageClass = StorageClass::None,
        public bool $isInline = false,
    ) {
        parent::__construct($loc);
    }
}

final class BinaryExpr extends Expr
{
    public function __construct(
        public BinaryOp $op,
        public Expr $left,
        public Expr $right,
        SourceLoc $loc,
        public ?CType $resolvedType = null,
    ) {
        parent::__construct($loc);
    }
}

final class CallExpr extends Expr
{
    public function __construct(
        public Expr $function,
        public array $arguments,
        SourceLoc $loc,
        public ?CType $resolvedType = null,
    ) {
        parent::__construct($loc);
    }
}

final class CompoundLiteralExpr extends Expr
{
    public function __construct(
        public CType $type,
        public Expr $initList,
        SourceLoc $loc,
        ?CType $resolvedType = null,
    ) { /* ... */ }
}

Les nœuds d'expression peuvent contenir resolvedType après l'analyse sémantique ; l'analyseur syntaxique construit d'abord la structure. L'analyse sémantique annote et vérifie les types directement, sans produire de réponse intermédiaire (IR) distincte.

Pourquoi les déclarateurs C sont difficiles

La grammaire déclarative du C est un piège classique. Il ne s'agit pas du même type :

int *p[4];      /* array of 4 pointers to int */
int (*p)[4];    /* pointer to array of 4 int */

La fonction parseDeclarator() implémente cette distinction. Le chemin non groupé applique d'abord *, puis [N] encapsule le type courant ; ainsi, *p[4] devient un tableau de pointeurs. Le chemin groupé (*p) construit un pointeur, peut collecter les dimensions entre parenthèses, puis applique les suffixes de fin avec applyArraySuffix(), qui réaffecte [N] à la pointée lorsque le type courant est déjà un pointeur.

// src/Compiler/Parser/Parser.php
private function applyArraySuffix(CType $type, ?int $count): CType
{
    if ($type instanceof PointerCType) {
        $to = $type->to;
        $array = $count !== null
            ? new ArrayCType($to, $count)
            : new IncompleteArrayCType($to);

        return new PointerCType($array);
    }

    return $count !== null
        ? new ArrayCType($type, $count)
        : new IncompleteArrayCType($type);
}

Cette fonction auxiliaire existe car une correction simpliste consistant à « appliquer le suffixe de tableau à l'ensemble du type » pour int (*p)[N] peut accidentellement réécrire int *p[N] et casser du code réel, y compris, historiquement, le chemin d'accès à SQLite. La fixture 051-pointer-to-array verrouille la lecture correcte :

int a[2][2] = { {1, 2}, {3, 4} };
int (*p)[2] = a;
return (*p)[0] + (*p)[1];

Littéraux composés et initialiseurs désignés

Les littéraux composés sont reconnus en position de conversion : (type){ ... } devient CompoundLiteralExpr au lieu de CastExpr lorsqu'une accolade initiale suit la parenthèse fermante.

Les initialiseurs désignés analysent une liste de désignateurs C99 (.field/[index]répété, puis=) pour obtenir soit un désignateur unique, soit un chemin imbriqué stocké dans InitListExpr. Ce chemin est ensuite normalisé pour les membres de structures et de tableaux imbriqués — le mécanisme sous-jacent au fixture 044-nested-designated-init`.

Représentation des types C en PHP

Toutes les classes de types principales se trouvent dans src/Compiler/Common/CType.php : primitives, PointerCType, ArrayCType, IncompleteArrayCType, FunctionCType, StructCType, UnionCType, EnumCType, qualificateurs et wrappers typedef.

Les questions que le compilateur pose à plusieurs reprises — taille, alignement, « est-ce un entier ? » — sont des méthodes sur CType utilisant match (true) et instanceof :

public function isInteger(): bool
{
    return match (true) {
        $this instanceof BoolCType,
        $this instanceof CharCType,
        // ...
        $this instanceof EnumCType => true,
        $this instanceof QualifiedCType => $this->base->isInteger(),
        $this instanceof TypedefCType => $this->base->isInteger(),
        default => false,
    };
}

Le fait que EnumCType soit un type entier a une incidence sur l'ABI : les paramètres d'une énumération doivent être stockés dans des registres généraux, comme les autres entiers. La taille et l'alignement suivent une disposition de type LP64 (4 entiers, 8 pointeurs, 4 énumérations ; les structures et les unions utilisent la taille et l'alignement de leur enregistrement). La taille des éléments d'un tableau est multipliée par son nombre ; les tableaux incomplets n'ont pas de taille.

La tension en C entre les tableaux et les pointeurs est omniprésente. Les tableaux perdent en performance dans de nombreux contextes d'expression, mais les types tableaux restent prioritaires dans les déclarateurs et pour l'optimisation arithmétique des pointeurs. Ne maîtriser qu'un seul de ces aspects, c'est risquer de livrer un compilateur qui, une fois lié, échoue toujours à l'opération *(a+1).

Analyse sémantique et résolution des symboles

Sema fait plus que « vérifier les types ».

Il gère des objets Scope imbriqués (global, function, block), une carte typedef, des types d'enregistrements et une table publique enumConstants :

// src/Compiler/Sema/Sema.php (excerpt)
final class Sema
{
  private Scope $globalScope;
  private Scope $currentScope;
  /** @var array<string, int> */
  public array $enumConstants = [];

  public function analyze(array $decls): array
  {
    foreach ($decls as $decl) {
      $this->collectTopLevel($decl);
    }
    foreach ($decls as $decl) {
      $this->analyzeDecl($decl);
    }
    return $decls;
  }
}

Le premier passage insère les fonctions, variables et typedefs de niveau supérieur, et enregistre les cas d'énumération. Le deuxième passage effectue une vérification de type du corps. L'enregistrement d'une énumération écrit à la fois la table de correspondance plate et une constante globale Symbol::enumConstant(...).

private function registerEnumConstants(EnumType $enumType): void
{
  foreach ($enumType->cases as $case) {
    $this->enumConstants[$case->name] = $case->value;
    $this->globalScope->insert(Symbol::enumConstant(
      name: $case->name,
      value: $case->value,
      type: IntCType::$instance,
    ));
  }
}

Les énumérations de type typedef et les énumérations anonymes imbriquées dans des structures alimentent également ce chemin d'enregistrement. La recherche d'identificateurs parcourt les portées, puis utilise enumConstants par défaut afin que VALUE dans int result = VALUE; soit résolu même si la seule déclaration était un cas d'énumération.

Scope est une carte liée à son parent, regroupant les valeurs de Symbol (Variable, Function, Typedef, EnumConstant). Le corps d'une fonction ouvre une portée de fonction globale ; les instructions composées s'imbriquent davantage. Les paramètres sont insérés avant l'analyse du corps.

Le pilote transmet ensuite explicitement enumConstants à codegen :

$codegen = new Codegen($enumConstants);

Cette conception fait du repliement constant des noms d'énumération dans les initialiseurs statiques un contrat partagé entre sema et le backend, et non une deuxième table de consultation indépendante inventée lors de l'émission.

Voici à quoi ressemble un chemin de parcours concret pour un initialiseur d'énumération global :

enum { VALUE = 42 };
int result = VALUE;

L'analyseur syntaxique construit un EnumDecl / type énuméré avec le cas VALUE = 42, puis un VarDecl dont l'initialiseur est un Identifier("VALUE"). Lors de la première passe de Sema, VALUE → 42 est enregistré dans enumConstants et dans la portée globale. Lors de la seconde passe, l'initialiseur est vérifié comme étant un entier. Au moment de générer le result global, Codegen résout l'identificateur via la table des constantes de l'énumération et génère une directive numérique (généralement .long 42) plutôt qu'une relocalisation symbolique. Le fixture 015-enum-global permet d'éviter que le chemin d'exécution ne régresse silencieusement vers une erreur d'« identificateur non déclaré » ou vers une erreur d'« émission de zéro ».

Le typage des expressions couvre également les aléas courants dont SQLite dépend encore : la dégradation des tableaux dans la plupart des contextes d’expression, les exigences relatives aux lvalues ​​pour l’affectation et l’opérateur unaire &, ainsi que les particularités liées à la position dans l’instruction, telles que (void)sizeof(x); (correctif 013-sizeof-stmt). sizeof est analysé comme un opérateur unaire pouvant accepter soit une expression, soit un nom de type entre parenthèses ; une erreur de classification à la position de l’instruction constitue un bogue de l’analyseur syntaxique qui n’apparaît jamais dans return 42.

Expressions constantes et initialisation statique

SQLite repose sur des données statiques : tables, chaînes de caractères, pointeurs vers des tableaux, initialiseurs composés. L’émission globale n’est donc pas une simple note de bas de page.

La fonction Codegen::emitInitializer() sélectionne les directives d'assemblage à partir du type cible. Les entiers étroits et les caractères deviennent .byte ; les entiers larges deviennent .long / .quad ; les tableaux parcourent chaque élément et .zero supprime les caractères restants ; les chaînes littérales converties en tableaux de caractères copient les octets et complètent le code. Les variables globales de tableaux de caractères sont définies par la fixture 010-char-array-global, qui exige .byte et interdit .quad 84 dans l'assembleur.

Une compilation en direct de ce composant produit actuellement :

.section __DATA,__data
.globl _table
.p2align 3
_table:
.byte 84
.byte 92
.byte 134
.byte 0

Ce résultat dépend de la correspondance entre instanceof ArrayCType et la classe réelle dans App\Compiler\Common. En PHP, un nom ArrayCType simple dans App\Compiler\CodeGen est résolu en App\Compiler\CodeGen\ArrayCType sauf s'il est importé. Un élément manquant :

use App\Compiler\Common\ArrayCType;

La branche du tableau est devenue inaccessible. Les variables globales ont été déplacées et ont généré des fichiers .quad au lieu de .byte. Le programme a pu être assemblé et lié. La disposition à l'exécution restait incorrecte. Il s'agit d'un bogue interlangage au sens strict : la résolution de noms PHP a corrompu la disposition des données statiques C.

Les initialiseurs globaux de pointeurs (&arr[i]), les définitions provisoires et les littéraux composés globaux sont des problèmes frères dans le même voisinage : le backend doit comprendre non seulement « émettre un entier », mais aussi « émettre une adresse relocalisable », « fusionner les définitions provisoires » et « matérialiser un agrégat constant dans la section de données ».

De l'AST typé à l'ARM64

Le backend est src/Compiler/CodeGen/Codegen.php, avec les conventions d'enregistrement dans Arm64.php :

const SCRATCH_REGS = [
    Arm64Reg::X9, Arm64Reg::X10, Arm64Reg::X11, Arm64Reg::X12,
    Arm64Reg::X13, Arm64Reg::X14, Arm64Reg::X15,
];

const ARG_REGS = [
    Arm64Reg::X0, Arm64Reg::X1, Arm64Reg::X2, Arm64Reg::X3,
    Arm64Reg::X4, Arm64Reg::X5, Arm64Reg::X6, Arm64Reg::X7,
];

La fonction RegAlloc alloue des registres temporaires. Les arguments sont reçus sous forme de x0 à x7, conformément à l'utilisation de type AAPCS64 dans ce backend. Les valeurs de retour sont de x0 (et de x1 pour les petits agrégats plus importants). L'assembleur est accumulé sous forme de chaînes de caractères et affiché comme du texte — une autre pratique native de PHP.

Une fonction concrète

Donné:

int add(int a, int b)
{
    return a + b;
}

ce compilateur génère (représentatif) :

.text
.globl _add
.p2align 2
_add:
stp x29, x30, [sp, #-16]!
mov x29, sp
sub sp, sp, #16
str x0, [x29, #-8]
str x1, [x29, #-16]
add x9, x29, #-8
ldrsw x9, [x9]
add x10, x29, #-16
ldrsw x10, [x10]
add x9, x9, x10
mov x0, x9
mov sp, x29
ldp x29, x30, [sp], #16
ret

Lire cela au regard de la mise en œuvre :

1. Le prologue sauvegarde le pointeur de cadre et le registre de lien, définit x29
2. Les variables locales/paramètres reçoivent des décalages négatifs par rapport à x29; les arguments sont stockés à partir de x0/x1
3. Les chargements utilisent ldrsw pour les valeurs signées 32 bits dans des registres 64 bits
4. add produit la somme dans un registre temporaire, puis la déplace vers x0.
5. L'épilogue restaure sp à partir de x29 et renvoie

La taille de la trame est calculée en fonction des besoins locaux et insérée dans un espace réservé sub sp, sp, #... émis au début de emitFunction(). L'alignement sur 16 octets est important sur AArch64 ; le backend arrondit/agrège les emplacements temporaires en conséquence.

Cadres de pile et variables locales

L'allocation locale est volontairement simple et explicite. emitFunction() réinitialise l'état de chaque fonction, émet une soustraction de trame de substitution, puis détermine l'espace mémoire nécessaire aux paramètres, aux variables locales et aux variables temporaires :

$this->emitLine('stp x29, x30, [sp, #-16]!');
$this->emitLine('mov x29, sp');
$this->emitLine('sub sp, sp, #0  ; FRAME_SIZE_PLACEHOLDER');
$this->framePlaceholderIndex = count($this->lines) - 1;

La fonction ensureLocalSpace() incrémente un localOffset continu, alignant chaque réservation sur 8 octets. La fonction allocLocal() stocke le décalage négatif choisi par rapport à x29 dans localVarOffsets.

private function ensureLocalSpace(int $size): void
{
    $aligned = ($size + 7) & ~7;
    $this->localOffset += $aligned;
    if ($this->localOffset > $this->frameSize) {
        $this->frameSize = $this->localOffset;
    }
}

private function allocLocal(string $name, CType $type): void
{
    $size = $type->sizeInBytes() ?? 8;
    $this->ensureLocalSpace($size);
    $offset = -$this->localOffset;
    $this->localVarOffsets[$name] = $offset;
    $this->localVarTypes[$name] = $type;
}

Les paramètres arrivant dans x0–x7 sont immédiatement répartis dans les emplacements correspondants (str x0, [x29, #-8], etc.). Cela confère à chaque variable locale nommée une adresse stable pour &var, pour la récupération des adresses de champs et pour le rechargement après les appels. Les structures de grande taille (> 16 octets) réservent également de l'espace pour le pointeur invisible x8 et le stockent en amont.

Lorsque le corps de la fonction est entièrement émis, la ligne d'espace réservé est raccordée à la véritable sub sp, sp, #<rounded frame> La taille de la trame est arrondie à l'entier supérieur afin que spreste aligné sur 16 octets — une exigence stricte sur AArch64. L'épilogue restaurespà partir dex29, retire la paire sauvegardée et ret`s.

Les variables temporaires composées, les emplacements de retour d'agrégats de petite taille et la mise en attente des arguments d'appel se disputent les mêmes ressources mémoire. C'est pourquoi les bogues d'ABI ressemblent souvent à une corruption de pile « aléatoire » jusqu'à ce qu'on remarque qu'une variable temporaire a été allouée avec une taille incorrecte ou qu'un appel imbriqué a écrasé un emplacement contenant encore un argument non évalué.

Arithmétique des pointeurs

Les opérations binaires + et - utilisant des opérandes de type pointeur adaptent la partie entière à la taille de la valeur pointée. Les tableaux sont considérés comme des opérandes de type pointeur à cet effet.

// src/Compiler/CodeGen/Codegen.php (excerpt)
$leftIsPtrLike = $leftType->isPointer() || $leftType->isArray();
$rightIsPtrLike = $rightType->isPointer() || $rightType->isArray();
// ...
} elseif ($ptrType instanceof ArrayCType || $ptrType instanceof IncompleteArrayCType) {
    $t = $ptrType->of->unqualified();
    $pointeeSize = $t->isPointer() ? 8 : ($t->sizeInBytes() ?? 4);
}
if ($pointeeSize > 1) {
    // lsl #1/#2/#3 or mul by immediate size
}

Avant la correction de Loop 32, *(a+1) pouvait renvoyer add ..., #1 en octets. Le fixture 035-array-ptr-arith nécessite désormais une mise à l'échelle des éléments.

Appel de fonctions sur ARM64

emitCallExpr() évalue les arguments, les répartit dans la pile dans un ordre discipliné, charge x0–x7 (et les arguments de la pile au-delà), puis soit bl _name pour les appels directs, soit blr xn pour les appels indirects.

Les pointeurs de fonction sont des types de première classe dans le système de types (PointerCType vers FunctionCType) et dans la génération de code. Un exemple minimal :

int call(int (*fn)(int), int value)
{
    return fn(value);
}

Émet une séquence d'appel indirect qui charge l'adresse de l'appelé et utilise blr (et non bl) vers un symbole fixe. Les appels directs de main vers call utilisent toujours bl _call, tandis que la récupération de l'adresse de id utilise adrp/add avec les relocalisations @PAGE / @PAGEOFF.

Appels variadiques

Les appels variadiques sont plus précis. L'évaluation des arguments peut avoir des effets de bord ; la durée de vie des registres et de la pile interagit mal avec l'émission naïve de gauche à droite, ce qui fausse les résultats précédents. Le fixture 016-variadic-spill est la forme réduite :

printf("%d%d%d", next(), next(), next());
return counter == 3 ? 42 : 1;

La sortie standard attendue est 123 avec le code de sortie 42. Le chemin d'exécution du backend, de type printf, évalue les arguments en variables temporaires sur la pile avant d'assembler la variable d'origine finale, évitant ainsi la perte d'incréments due à la réutilisation des registres. Générer du code ARM64 syntaxiquement valide est bien plus simple que d'implémenter une convention d'appel qui résiste aux arguments à effets de bord.

Faibles rendements agrégés

Apple ARM64 renvoie des agrégats d'au maximum 16 octets dans x0 (et x1 si supérieur à 8). emitSmallAggregateReturn() matérialise la valeur dans un emplacement de pile, puis charge x0/x1 :

} elseif ($value instanceof CallExpr) {
    $this->emitExpr($value);
    $this->emitLine('str x0, ['.$addrReg->x().']');
    if ($size > 8) {
        $this->emitLine('str x1, ['.$addrReg->x().', #8]');
    }
}
// ...
$this->emitLine('ldr x0, [sp]');
if ($size > 8) {
    $this->emitLine('ldr x1, [sp, #8]');
}

La branche CallExpr existe car le transfert de return a(); à l'intérieur d'une autre fonction renvoyant une structure doit préserver l'intégralité du résultat du registre de l'appel imbriqué. Ne stocker qu'une représentation 32 bits de x0 entraîne la perte d'un champ. Ceci correspond à la boucle 48 / fixture 054-struct-return-chain.

Dans l'assembleur généré pour b, vous pouvez voir le modèle : bl _a, puis str x0, [...], puis ldr x0, [sp] avant de retourner — le petit agrégat est traité comme une valeur de largeur de registre, et non comme un seul w0 restant d'une mentalité scalaire.

Structures, unions et littéraux composés

La disposition des structures et des unions est calculée lors de l'analyse de la définition d'enregistrement, puis stockée dans un RecordType consulté ultérieurement par StructCType / UnionCType. Pour les structures, chaque champ est aligné sur son propre alignement, les décalages s'accumulent et la taille totale est arrondie à l'alignement maximal de l'enregistrement.

// src/Compiler/Parser/Parser.php (struct field layout excerpt)
$fieldAlign = $fieldType->alignOf() ?? 1;
$fieldSize = $fieldType->sizeInBytes() ?? 0;
$maxAlign = max($maxAlign, $fieldAlign);
$byteOff = ($byteOff + $fieldAlign - 1) & ~($fieldAlign - 1);
$fields[] = new RecordField(
    name: $fieldName,
    type: $fieldType,
    bitWidth: null,
    offset: $byteOff,
    bitOffset: 0,
);
$bitOffset = ($byteOff + $fieldSize) * 8;
// ...
$totalBytes = intdiv($bitOffset + 7, 8);
$totalBytes = ($totalBytes + $maxAlign - 1) & ~($maxAlign - 1);
$rec = new RecordType(name: $tag ?? '', fields: $fields, size: $totalBytes, alignment: $maxAlign);

Les unions prennent la taille maximale des membres (arrondie à l'alignement maximal) et placent chaque champ à l'offset 0. Les champs de bits existent également dans le chemin de structure du parseur ; ils suivent les décalages de bits au sein des unités de stockage. Codegen utilise les décalages de champ lors de l'émission de l'accès aux membres (ajout d'une constante à une adresse de base) et lors de la mise en place des initialiseurs de structure globaux (insertion d'un remplissage .zero entre les positions de champ désignées).

Ces informations de mise en page rendent possibles les arguments agrégés, les retours et les littéraux composés : sans décalages fiables, « champ b d'une structure de 8 octets » relève de la conjecture.

Les littéraux composés sont abaissés en matérialisant un élément temporaire :

// emitAddr() path for CompoundLiteralExpr
if ($expr instanceof CompoundLiteralExpr) {
    // allocate frame slot, compute address in a register
    $this->emitLocalInit($reg, $expr->initList, $expr->type);
    return $reg;
}

Passer (struct S){20, 22} comme argument signifie donc : construire la variable temporaire, puis passer l’agrégat de la mémoire dans les registres d’arguments ou la pile en fonction de sa taille — et non « évaluer la liste d’initialisation comme s’il ne s’agissait que du premier champ ». Le fixture 034-compound-lit-arg existe parce que cette erreur a renvoyé 20 au lieu de 42.

Les initialiseurs désignés imbriqués ({.iy = 2, .ix = 1}, {.a[1] = 40}) exigent que le normaliseur d'initialiseurs parcoure les chemins de désignation dans les structures et tableaux imbriqués, y compris à travers les membres anonymes lorsqu'ils sont présents. Le fixture 044-nested-designated-init est la sonde réduite.

La limite de la chaîne d'outils native

Toolchain est volontairement minimaliste :

// src/Compiler/Platform/Toolchain.php
public function assemble(string $asmPath, string $objectPath): ProcessResult
{
    return $this->run(['/usr/bin/as', $asmPath, '-o', $objectPath]);
}

public function link(array $objectPaths, string $outputExecutable, array $extraArgs = []): ProcessResult
{
    $args = array_merge(
        ['/usr/bin/clang', ...$objectPaths, '-o', $outputExecutable, '-lm', '-lpthread', '-ldl'],
        $extraArgs
    );
    return $this->run($args);
}

La fonction run() utilise proc_open, capture la sortie standard et la sortie d'erreur, et renvoie un code de sortie. Cela suffit. PHP écrit les fichiers .s ; as écrit les fichiers .o ; le pilote Clang effectue les liens. Clang ne compile toujours pas le code source C sur le chemin d'acceptation.

SQLite en tant qu'oracle d'intégration

La compilation de return 42 prouve que le canal est connecté. La compilation de SQLite prouve que les sous-systèmes interagissent.

Le script (fixtures/compiler/sqlite_smoke_test.c) ouvre :memory:, crée une table, y insère 'darkwood', la sélectionne et affiche le texte. Cela sollicite une unité de traduction importante, des en-têtes riches en macros, des données globales, des pointeurs de fonction, des structures, des énumérations et une quantité suffisante de conventions d'appel pour que des erreurs de débordement de tampon provoquent des échecs à l'exécution, même si l'assembleur semble correct.

SQLite n'est pas une suite de standards. C'est un oracle d'intégration : de nombreuses fonctionnalités doivent être quasiment parfaites simultanément, sinon le test de validation échoue.

Les bugs de l'implémentation exposés

Le principal atout technique de ce projet réside dans l'ensemble des bogues qui n'ont été mis en évidence que par la confrontation d'abstractions. Chaque cas présenté ci-dessous suit le même schéma : petit programme C, comportement attendu, comportement anormal, cause racine en PHP, correctif, fixture.

Étude de cas : ArrayCType et données statiques corrompues

Programme (010-char-array-global) :

static const unsigned char table[4] = {84, 92, 134, 0};
int main(void) { return table[0]; }

Résultat attendu : sortie 84; l’assembly contient .byte, et non .quad 84.

Mode d'échec : l'absence de use App\Compiler\Common\ArrayCType; dans Codegen.php a entraîné le test de la mauvaise classe par instanceof ArrayCType. La branche d'initialisation du tableau ne s'est jamais exécutée. Des directives plus larges ont mal agencé le tableau.

Correction : importer la classe réelle ; émettre un .byte par élément pour les tableaux de caractères. Conservé explicitement dans les notes d’état du projet et verrouillé par les assertions d’assemblage des fixtures.

Leçon : une erreur d’espace de noms PHP est un bug d’ABI/de structure C. « Liens » ne signifie pas « fonctionne ».

Étude de cas : mise à l’échelle arithmétique des pointeurs de tableaux

Programme (035-array-ptr-arith) :

int a[3] = {10, 20, 12};
int *p = a + 1;
return *(a + 2) == 12 && *p == 20 ? 42 : 0;

Attendu : sortie 42 (également comparé avec clang).

Mode d'échec : a + 1 avancé d'octets car les tableaux n'ont pas été traités comme des pointeurs pour la mise à l'échelle.

Correction : dans emitBinaryExpr, traiter ArrayCType comme un pointeur pour +/-, mettre à l'échelle par sizeof(element) via lsl/mul.

Leçon : la dégradation des tableaux et la mise à l’échelle des pointes ne sont pas le même bug, mais ils sont étroitement liés.

Étude de cas : déclarations de pointeurs vers des tableaux

Programme (051-pointeur-vers-tableau) :

int (*p)[2] = a;
return (*p)[0] + (*p)[1];

Résultat attendu : correspond à clang.

Mode d'échec : l'application du suffixe déclaratif qui a réparé (*p)[N] pourrait casser *p[N] si elle est appliquée de manière trop large.

Correction : Fermez le déclarateur (*name) groupé avant les suffixes de tableau ; utilisez applyArraySuffix() pour que [N] pointe vers un pointeur de type pointeur. Conservez le chemin non groupé pour la construction de tableaux de pointeurs de manière classique.

Leçon : Les déclarateurs C posent un problème d’analyse syntaxique avec des conséquences sémantiques ; les fixtures doivent couvrir les deux interprétations.

Étude de cas : arguments littéraux composés

Programme (034-compound-lit-arg) :

return f((struct S){20, 22});

Attendu : 42.

Mode d'échec : l'évaluation d'une liste littérale composée / init comme valeur n'a renvoyé que le premier champ (20).

Correction : matérialiser le littéral composé dans un cadre temporaire dans emitAddr, puis passer la structure ≤16 octets de la mémoire dans les registres d'arguments.

Leçon : les agrégats éphémères ont besoin d’adresses, et non d’un « premier scalaire ».

Étude de cas : initialiseurs désignés imbriqués

Programme (044-nested-designated-init) :

struct Outer o = {.z = 3, .i.y = 2, .i.x = 1};
struct Arr s = {.a[1] = 40, .a[0] = 2};

Résultat attendu : les valeurs des champs et des emplacements de tableau correspondent à la lecture de clang.

Mode d'échec : les désignateurs à un seul niveau fonctionnaient ; les chemins imbriqués et les désignateurs de tableau à l'intérieur des structures ne fonctionnaient pas.

Correction : analyser les listes de désignateurs en chemins ; normaliser ces chemins lors de l’application des initialiseurs, y compris à travers les membres imbriqués et anonymes.

Leçon : L’initialisation simplifiée du C99 n’est pas optionnelle si vous prétendez utiliser du « vrai C » plutôt qu’un code de type SQLite.

Étude de cas : déversements variadiques

Programme (016-variadic-spill) :

printf("%d%d%d", next(), next(), next());

Résultat attendu : stdout 123, sortie 42.

Mode d'échec : l'ordre d'évaluation des arguments / la durée de vie des registres ont été détruits par les résultats précédents de next() avant l'appel.

Correction : évaluer dans des temporaires de pile, puis assembler l'appel variadique à la maison (le chemin en forme de printf dans emitCallExpr).

Leçon : les arguments à effets secondaires sont un test ABI, et non un test d’analyse syntaxique.

Étude de cas : chaînes de retour de structures

Programme (054-struct-return-chain) :

struct S b(void) { return a(); }
// main: struct S s = b(); return s.a + s.b;

Résultat attendu : sortie 3 (oracle clang).

Mode d'échec : le retour agrégé imbriqué n'a préservé qu'une partie de x0 (sortie symptomatique 2).

Correction : dans emitSmallAggregateReturn(), lorsque l'expression renvoyée est une CallExpr, stockez x0 complet et, si nécessaire, x1 avant de recharger pour le retour de la fonction actuelle.

Leçon : générer ret après bl n’est pas la même chose que de mettre en œuvre le transfert de retour agrégé.

Des échecs aux tests de régression

La méthodologie est plus importante que n'importe quel KEEP individuel :

SQLite failure (or clang mismatch)
  → identify subsystem
  → reduce to a tiny C program
  → compare observable behavior
  → create fixtures/compiler/NNN-*.c + .json
  → fix one narrow behavior
  → run app:compiler-fixtures
  → run app:compiler-sqlite
  → KEEP only if still valid

Les métadonnées des fixtures peuvent vérifier les codes de sortie, la sortie standard, les sous-chaînes d'assemblage et compareWithClang. Les assertions d'assemblage permettent de détecter les erreurs de mise en page qu'un code de sortie chanceux pourrait manquer. Le fait que la suite se termine à 46/46 n'est pas un simple effet de mode ; il s'agit d'un souvenir des interactions qui ont déjà affecté l'amalgame.

Sondes différentielles

Pour les petits programmes, la compilation et l'exécution du même code source avec clang fournissent un oracle exécutable : le code de sortie et la sortie standard. Des commandes telles que app:compiler-compare-clang et les flux de test existent pour faciliter ce processus. Clang est ici un outil de comparaison différentielle à l'exécution, et non le compilateur de sqlite3.c dans le cadre de la validation.

Cette distinction est importante. Les tests différentiels répondent à la question : « Notre ABI correspond-elle au comportement observable sur cette sonde ? » Les tests d’acceptation répondent à la question : « Notre compilateur compile-t-il SQLite ? »

Où Darkwood Flow trouve sa place

La compilation comprend deux pipelines différents. Les confondre produit soit une abstraction inutile, soit une réimplémentation privée d'un élément qui devrait être partagé.

Le pipeline algorithmique est étroitement couplé :

tokens → AST → semantic model → assembly

Ces étapes échangent des structures spécifiques au compilateur : listes de jetons, arbres de déclarations, graphes de types C et allocateurs de registres. Encapsuler chaque étape d'analyse syntaxique dans un framework d'orchestration n'apporterait aucune clarté. L'algorithme de masquage d'ensembles ne s'améliore pas du simple fait de son passage par une file d'attente de tâches.

Le processus opérationnel est différent :

compile → assemble → link → execute → validate

Chaque étape possède des limites d'artefacts clairement définies, peut échouer indépendamment, peut enregistrer le temps d'exécution sur un état partagé et peut être remplacée sans réécrire l'analyseur lexical. C'est là que Darkwood Flow trouve toute sa place.

Ce projet dépend du paquet Composer darkwood/flow v8.1.5. Le noyau du compilateur situé dans src/Compiler/ n'importe pas Flow. Les workflows externes situés dans src/Flow/, en revanche, les importent.

SqliteValidationFlow génère des tâches planifiées. Son API est volontairement réduite : une FlowFactory construit un flux à partir d'un générateur de tâches ; chaque tâche reçoit un Ip (paquet d'informations) contenant un SqliteValidationState ; await() exécute la séquence jusqu'à son terme.

// src/Flow/SqliteValidationFlow.php
$flow = (new FlowFactory())->create(function () {
    yield $this->timed('compile_sqlite', $this->compileSqlite);
    yield $this->timed('assemble_sqlite', $this->assembleSqlite);
    yield $this->timed('compile_harness', $this->compileHarness);
    yield $this->timed('assemble_harness', $this->assembleHarness);
    yield $this->timed('link', $this->linkSmokeExecutable);
    yield $this->timed('run', $this->runSmokeTest);
});

$flow(new Ip($state));
$flow->await();

La fonction timed() est un wrapper PHP classique autour d'une JobInterface : elle ignore le travail restant si failure est déjà défini, lance la tâche et stocke le temps écoulé en millisecondes dans $state->timings. Les tâches concrètes (CompileSqlite, AssembleSqlite, CompileHarness, AssembleHarness, LinkSmokeExecutable, RunSmokeTest) font appel à Compiler et Toolchain. Flow ne reconnaît pas la notion de Token.

Du point de vue de l'utilisateur, il n'y a qu'une seule commande :

php -d memory_limit=4G bin/console app:compiler-sqlite

En interne, cela se décompose en étapes indépendantes et significatives partageant SqliteValidationState : PHP produit sqlite3.s, as produit sqlite3.o, PHP génère l'assembly Harness, as produit l'objet Harness, l'éditeur de liens produit un exécutable, le processus affiche darkwood, la validation confirme la réussite. Les flux apparentés (CompileFlow pour la compilation/l'assemblage/l'édition de liens d'un seul fichier, ProbeRunFlow pour les tests de base de Clang) appliquent le même principe à plus petite échelle.

Une correction architecturale a été apportée : une version miniature locale de l’environnement d’exécution Flow, située dans src/Flow/Runtime/, a été supprimée. L’expérimentation du compilateur doit désormais utiliser le package Composer officiel au lieu de maintenir une copie privée. La séparation finale est la suivante :

sqlite-compiler-php
  ├── src/Compiler/   plain PHP algorithms
  └── src/Flow/       darkwood/flow orchestration

Il est tout aussi important de comprendre ce que Flow n'a pas été conçu pour faire. Il ne remplace pas les nœuds AST, n'implémente pas l'expansion des macros, n'alloue pas de registres, n'émet pas de code ARM64, ne remplace pas Symfony ni la chaîne d'outils du système d'exploitation. Il ne s'agit pas d'une couche de performance et il n'a jamais été conçu pour accélérer la compilation de SQLite. Sa valeur réside dans la structure et la visibilité qu'il offre autour d'une compilation native multi-étapes — une application concrète de Darkwood Flow à un contexte très différent d'une requête web.

En bref : le compilateur montre ce que PHP natif peut faire ; Darkwood Flow transforme ces capacités en une expérience reproductible.

La boucle d'itération

Le développement s'est déroulé comme un processus de découverte au-delà de la simple implémentation, et non comme une réécriture unique et inspirée.

Le modèle est le développement de compilateurs différentiels :

construct probe
  → compile with this compiler
  → compile/run with clang when useful
  → compare observable behavior
  → isolate mismatch
  → reduce fixture
  → inspect parser / sema / codegen
  → modify one narrow behavior
  → run fixture suite
  → run SQLite
  → KEEP only if still valid

L'argument pertinent n'est pas qu'un modèle puisse générer des milliers de lignes de PHP, mais qu'un agent puisse interagir de manière répétée avec du code de compilateur réel, du code as/clang réel, des fixtures réelles et une cible d'acceptation importante — pour ensuite ne conserver que les modifications validées.

La discipline apparaissait encore comme un refus d'inventer du travail en retard, et comme un arrêt lorsque de nouveaux changements n'étaient plus justifiés par des enquêtes infructueuses.

La boucle

Après des boucles d'ingénierie axées sur la correction à travers la boucle (chaîne de retour de structure / 054-struct-return-chain), une boucle de réveil a continué à reprendre un agent toutes les cinq minutes avec des instructions pour rechercher la prochaine amélioration la plus importante.

Trois termes doivent rester distincts :

Terme	Signification
Boucle de réveil	Reprise périodique : analyse, validation, décision quant à l’opportunité de modifications.
Boucle d'ingénierie	Une entrée KEEP numérotée.
Modification conservée	Code validé et enregistré : CONSERVER.

Les ticks ne correspondent pas à des modifications de code. La boucle de réveil a été interrompue. Entre ces deux événements, une longue période de ticks a révélé que la suite était toujours au vert (46/46, SQLite affichant toujours darkwood), sans qu'aucune anomalie significative ne justifie un autre KEEP.

Si la boucle de veille avait continué à inventer des refactorisations sans qu'une sonde ne soit défaillante, cela n'aurait été que du bruit déguisé en progrès. La conclusion intéressante est d'ordre méthodologique :

Finalement, la boucle de rétroaction a convergé vers des décisions de maintien du statu quo.

Ce que le compilateur prend en charge

Suffisamment de C pour compiler et exécuter le chemin de fumée d'amalgame SQLite 3.46.0 sur macOS ARM64, plus un réseau de régression de 46 fixtures couvrant les bords du préprocesseur, les variables globales, les littéraux composés, les énumérations, les modèles de déversement variadiques, les déclarateurs, les initialiseurs désignés et les cas d'ABI agrégés.

Ce qu'il ne cherche pas délibérément à être

• Ne constitue pas une allégation de conformité totale aux normes C99/C11/C17
• Aucun optimiseur CIR/IR n'est intégré par conception.
• Ne remplace pas Clang/GCC en production
• Un récit de compatibilité avec le SDK Darwin incomplet
• L'ABI à virgule flottante et d'autres écarts plus importants restent en dehors de la barre « SQLite smoke + current fixtures ».
• L'IA ne supprime pas la nécessité de tests d'acceptation exécutables

Il est préférable d'utiliser la formulation exacte : assez du sous-ensemble C utilisé par SQLite et les tests de régression actuels.

Ce que j'ai appris

PHP peut héberger une implémentation de compilateur non triviale utilisant des objets ordinaires, des tableaux, la distribution instanceof, de l'assembleur construit à partir de chaînes de caractères et proc_open pour les outils natifs. Un chemin direct lexer → préprocesseur → analyseur syntaxique → sema → ARM64 permet de gérer suffisamment de code C pour compiler l'amalgame de SQLite et exécuter un véritable système de simulation de fumée.

Les bogues les plus difficiles n'étaient pas dus à un simple point-virgule oublié dans l'émetteur. Il s'agissait d'interactions complexes : espaces de noms PHP vs structure C, équivalence entre tableaux et pointeurs, arbres de déclarateurs, transfert d'ABI agrégé, ordre d'évaluation variadique. SQLite impose ces interactions. Les fixtures les mémorisent.

Darkwood Flow a mérité sa place en tant que pipeline externe. Il n'avait pas sa place au sein du flux de jetons.

La boucle de rétroaction tardive a permis de tirer une leçon plus discrète. L'absence de changement persistant après l'analyse prouve que la boucle fonctionne et que l'expérience a atteint un point d'arrêt qu'il convient de respecter.

Où je l'emmènerais ensuite

Les prochaines étapes importantes sont plus ambitieuses : une interface utilisateur logicielle (ABI) plus étendue pour les nombres à virgule flottante, une couverture plus large du langage C au-delà du sous-ensemble de type SQLite, et peut-être des stratégies de streaming ou d’émission plus légères. Aucune de ces solutions ne peut être considérée comme un simple « maintien de cinq minutes », et aucune ne devrait être relancée sans une procédure de validation rigoureuse.

Pour Darkwood, la leçon à retenir est d'ordre architectural : conserver les algorithmes du compilateur en PHP pur ; conserver les pipelines opérationnels dans Flow ; insister sur le fait que « fonctionne » signifie des fixtures plus un test d'acceptation rigoureux — et non pas simplement quelque chose d'assemblé.

Sources

• Code source : https://github.com/matyo91/sqlite-compiler-php
• Slides : https://github.com/matyo91/slidewire

• Poster un commentaire