Poppy TeamEN
Poppy Team

Português

English

Português

English

Aparência

EN
AipoLinguagem dinâmicaSobre o projetoRepositório ↗

Cópia estática

Copiado de docs/decisions/adp-013.md em https://github.com/poppy-team/aipo-lang (MIT). Fixado na revisão ce47c4e070404fc41722ccd8e2b7b808b99062a8, blob 5685d87ff203932dad1461d354dda41607566458. O repositório de origem permanece canônico; esta cópia é atualizada por um pull request de sincronização, não em tempo real.

ADP-013 — Migração para Substrato de Execução WebAssembly e Roteiro de Self-Hosting ​

  • Status: Aprovado
  • Data: 2026-09-26
  • Decisores: Raillen & Poppy Team
  • Fase: Transição Arquitetural / v0.11.0 (Wasm Core & Self-Hosting Foundation)

Contexto e Diagnóstico Técnico ​

Durante o desenvolvimento da release v0.1.0 da linguagem Aipo, foram implementadas e medidas empiricamente otimizações profundas no interpretador de bytecode (P1 compactação de layout de Value, P2 despacho direto de métodos de structs, P4 superinstruções GetLocal0..7 e Call0..4, e E1 falhas estruturadas tipadas).

Apesar dos ganhos expressivos mensurados em benchmarks pareados (até -13,94% de CPU), a análise microarquitetural de hardware comprovou a existência de um piso de despacho físico de ~100ns por opcode no interpretador baseado em pilha (Stack VM):

  1. Poluição do Branch Target Buffer (BTB): O laço de despacho centralizado (match opcode) em Rust seguro provoca uma taxa de erro de previsão de salto (branch misprediction) superior a 60%, custando 15 a 20 ciclos de clock de penalidade pura por instrução executada (pipeline stall).
  2. Multiplicação de Instruções de Pilha: Máquinas de pilha requerem de 3x a 4x mais instruções de bytecode para realizar a mesma computação lógica que máquinas de registradores ou código compilado.
  3. Barreira ao Self-Hosting: Para viabilizar que a própria linguagem Aipo implemente seu compilador (self-hosting), depender de bibliotecas massivas em C/Rust (como LLVM ou Cranelift nativo) exigiria bindings de FFI frágeis e pesados, criando um acoplamento indesejado no ecossistema.

Decisões Arquiteturais ​

1. Congelamento da Edição v0.1.0 (Stack VM) ​

  • A implementação atual da máquina virtual baseada em pilha (aipo-vm), com a C ABI (aipo-c-abi), o test runner (aipo test) e todos os 506+ testes verdes, é formalmente congelada na branch legacy/v0.1.0-stack-vm e tagueada como v0.1.0-stack-vm-final.
  • Esta branch preserva a referência histórica completa e funcional da primeira versão da linguagem.

2. Adoção do WebAssembly (Wasm 2.0 + WASI) como Substrato de Execução ​

  • A Aipo adota o WebAssembly como formato binário alvo de compilação e execução padrão.
  • O código compilado passa a ser um arquivo .wasm padronizado, executado com performance nativa via JIT do Wasmtime (usando o backend Cranelift) em ambientes desktop/servidor, e executado nativamente em navegadores e runtimes JavaScript (Node.js, Deno, Bun, Cloudflare Workers).

3. Preservação Integral do Frontend (100% Reutilizado) ​

  • As camadas de frontend permanecem intactas e inalteradas:
    • aipo-source (mapeamento de código, spans e localizações).
    • aipo-diagnostics (códigos de erro, severidade e relatórios).
    • aipo-lexer e aipo-syntax (tokens, parser e árvore sintática abstrata).
    • aipo-hir e aipo-sema (checagem de tipos, escopos, contratos de interface e semântica).

4. Reestruturação do Middle-End (aipo-ir) ​

  • O aipo-ir é adaptado para gerar Structured Control Flow (block, loop, if ... else, br, br_if, br_table), eliminando saltos arbitrários em favor de uma representação compatível com o modelo formal do WebAssembly.

5. Criação do Backend aipo-wasm ​

  • A crate aipo-bytecode (formato proprietário .aibc) é sucedida pela crate aipo-wasm.
  • aipo-wasm gera diretamente arquivos binários .wasm utilizando a biblioteca Rust pura e de alta performance wasm-encoder.

6. Casamento Natural entre aipo-host e WASI ​

  • O modelo de segurança por capacidades da Aipo (CapabilitySet, deny-by-default) mapeia-se de forma direta para a arquitetura de capacidades do WASI (WebAssembly System Interface) e do Wasm Component Model, garantindo isolamento criptográfico e segurança de execução.

7. Roteiro Estratégico de Self-Hosting em Três Fases ​

  1. Fase 1 (Wasm Foundation): Compilador em Rust gera módulos .wasm funcionais executados via runtime Wasmtime integrado ao CLI.
  2. Fase 2 (Frontend em Aipo): Reescrita dos módulos de parsing, análise semântica e emissor Wasm na própria linguagem Aipo (aipo-in-aipo), aproveitando os tipos de dados nativos (Bytes, List, Dict, Struct).
  3. Fase 3 (Bootstrapping Fechado): O compilador Aipo em Rust compila o compilador Aipo em Aipo gerando aipo-compiler.wasm. A partir deste marco, o compilador torna-se auto-hospedado, verificável por determinismo estrito bit-a-bit (bit-for-bit identity check).

Consequências e Trade-Offs ​

Positivas ​

  • Salto de Performance de 30x a 50x: Execução JIT via Cranelift aproxima a velocidade da Aipo da velocidade de linguagens compiladas como Go e C.
  • Portabilidade Universal sem Transpilação: O mesmo arquivo .wasm roda identicamente no terminal, na web, em servidores e em engines nativas (como a Poppy).
  • Self-Hosting Trivilializado: Wasm é uma especificação pura de bytes; emitir binários .wasm a partir da Aipo requer zero pontes C-ABI ou dependências de bibliotecas de baixo nível.
  • Eliminação de Código Duplicado: O backend aipo-js deixa de ser um transpilador de código-fonte complexo e torna-se um loader nativo de módulos Wasm.

Desafios Técnicos a Gerenciar ​

  • Controle de Fluxo Estruturado: Requer algoritmo de relayout de laços e condições no aipo-ir (Relooper/Stackifier).
  • Gerenciamento de Memória Dinâmica: Estratégia de alocação de memória linear com alocador embutido leve e suporte futuro a Wasm GC.
  • Concorrência e Async: Implementação de máquina de estados compilada para tarefas assíncronas cooperativas.