[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · IR Binário de 128 Bits

A Linguagem de Programação Binária de 128 Bits para IA.

A IA pensa em números e as CPUs rodam binário — mas C, Go e Rust forçam a IA a digitar texto humano e esperar segundos para um compilador adivinhar sua intenção. Rul (.rl) elimina esse intermediário de texto: a IA emite blocos binários fixos de 16 bytes contendo Algoritmo, Escalonamento de CPU e Bilhete de Segurança de Memória desde o início. Resultado: verificação de segurança em 5.8 ns, compilação autônoma em 6.4 µs e execução 4.72x mais rápida que C escrito à mão.

PRIMEIROS PRINCÍPIOS EM 10 SEGUNDOS · ELIMINE O INTERMEDIÁRIO DE TEXTO

✗ JEITO ANTIGO (C / Go / Rust) IA Pensa (Números) → Digita Texto Humano → Compilador Analisa & Adivinha Intenção (Segundos) → Código de Máquina (0/1)

✓ PRIMEIROS PRINCÍPIOS RUL (.rl) IA Pensa (Números) → Emite Bloco Binário de 16 Bytes (Prova 5.8 ns + Compilação 6.4 µs) → Roda 4.72x Mais Rápido que C

Bloco Binário de 16 Bytes (0ms Parse) + 6.4 µs ELF64 Nativo (Zero LLVM) + Prova de Segurança 5.8 ns (O(N) Linear)

# 1. Install standalone rul binary (0 rustc/LLVM runtime deps)
$ curl -fsSL https://raw.githubusercontent.com/rul-lang/rul/main/install.sh | sh

# 2. Scaffold, O(N) verify in ~5.8ns/node, compile 817B ELF64 & trace
$ rul new my-ai-pipeline && cd my-ai-pipeline
$ rul check   # ✓ Verified 7 SSA nodes in 0.04 µs (CAP_NONE = 0x0)
$ rul run     # ✓ Compiled 817-byte ELF64 in 6.4 µs -> Output: 77999800.0
$ rul trace   # ✓ White-Box Inspector: #0..#6 (NaN/Inf = 0)

Inspecionar Quadro de 16B ↓ Ler Espec. v0.4 Whitepaper (DOI) ↗

IMAGEM BINÁRIA .RL AO VIVO · 7 NÓS SSA = 208 BYTES -> ELF64 DE 817 BYTES CAP_NONE=0x0

Clique em qualquer quadro de instrução de 16 bytes abaixo para decodificar seus bits, prova do verificador e rastreamento:

RulHeader

64 Bytes (0x00..0x3F)

Arena[0] + Proof[0]

32 Bytes (0x40..0x5F)

NodeFrame[0..6]

112 Bytes (7 × 16B)

#0 ArenaInput

01 18 11 00 · read(0,1) · a=0 b=0

#1 ConstF64

02 11 11 00 · pure · const=100.0

#2 CmpGt

14 38 11 00 · pure · a=$n0 b=$n1

#3 Mul

12 18 12 00 · pure · a=$n0 b=$n0

#4 SelectZero

15 18 11 00 · pure · a=$n2 b=$n3

#5 ReduceSum

21 11 11 00 · pure · a=$n4 b=0

#6 AssertContract

40 11 11 00 · pure · a=$n5 b=0

Artifact (.rl) = Algorithm + Schedule + Proof ✓ 5.78 ns/node

[0x40] Quadro de 128 Bits

16 Bytes

Cada Instrução É um Bloco Binário Fixo · 0 ms de Análise de Texto

[0x50] por instrução

5.78 ns

Prova Instantânea de Memória & Limites (Passagem Única O(N))

[0x60] compilação nativa

6.4 µs

Binário Linux x86_64 ELF64 Autônomo Sem LLVM

[0x70] 4.72x vs C

51.53 GB/s

10M de Números (80 MB) Acelerados pela Mutação de 1 Byte

[0x80] BANCADA INTERATIVA DE 128 BITS

ALIGN=64B · FRAME=16B (128-BIT)

Uma Instrução de 16 Bytes = Algoritmo + Escalonamento + Prova

Selecione qualquer nó de instrução (#0..#6) ou clique em qualquer byte (0..15) para inspecionar seu registrador binário de 8 bits, testemunha de segurança O(N) e rastreamento de execução caixa-branca.

Faixa de Algoritmo (O que calcular: Opcode / Operandos) Faixa de Escalonamento (Como rodar: SIMD / MultiCore) Faixa de Prova (Segurança: Bilhete de Versão / Limites)

NODE #3 ($n3) node $n3 = Mul f64x8 fg=1 pol=simd proof=0 tok=pure a=$n0 b=$n0

16 BYTES = 128 BITS

ANÁLISE DO REGISTRADOR DE 8 BITS · BYTE 2 (b16..b23) 0x12

0 2^7

0 2^6

0 2^5

1 2^4

0 2^3

0 2^2

1 2^1

0 2^0

Campo: schedule_hint Tipo: u8

✓ Invariante do Verificador O(N) Checado no Carregamento (~5.78 ns) (fusion_group << 4) | exec_policy

Byte ortogonal de escalonamento de hardware: mutar 0x11 (SimdStream) -> 0x12 (MultiCore) altera a execução da CPU sem alterar as provas de segurança.

Nó #3: Quadrado vetorial elemento a elemento de 8 vias ($n0 * $n0) fusionado em registradores de cache L1 com zero alocação no heap.

Visão de Montagem Simbólica (src/main.rls — 208 B em .rl) ~8.8 µs assemble

cap 0x0

arena 0 len=4096 lane=f64x8 mut=false align=64 ver=1

output $n6

Rastreador de Execução Caixa-Branca (rul trace — 7 Nós SSA) Clique em qualquer linha para sincronizar o quadro binário de 16 bytes e a montagem

NODE	OPCODE	KIND	LEN	MIN	MAX	SUM/TRUES	SAMPLE[0..4]
#0	ArenaInput	ColumnF64	4096	0.5000	249.5000	504608.0000	[0.500, 1.500, 2.500, 3.500]
#1	ConstF64	Scalar	1	100.0000	100.0000	100.0000	[100.000]
#2	CmpGt	ColumnMask	4096	0.0000	1.0000	2400.0000	[0.000, 0.000, 0.000, 0.000]
#3	Mul	ColumnF64	4096	0.2500	62250.2500	83627904.0000	[0.250, 2.250, 6.250, 12.250]
#4	SelectZero	ColumnF64	4096	0.0000	62250.2500	77999800.0000	[0.000, 0.000, 0.000, 0.000]
#5	ReduceSum	Scalar	1	77999800.0000	77999800.0000	77999800.0000	[77999800.000]
#6	AssertContract	Scalar	1	77999800.0000	77999800.0000	77999800.0000	[77999800.000]

[0x100] MUTAÇÃO DE ESCALONAMENTO DE HARDWARE EM 1 BYTE

ALIGN=64B · FRAME=16B (128-BIT)

Mute 1 Byte (Byte 2). Acelere 4.72x Além do C Escrito à Mão.

Carga de trabalho real: 10.000.000 de números de ponto flutuante (array de 80 MB) — filtrar valores > 1000.0, elevar ao quadrado e somar em um único resultado. Clique para mutar o Byte 2 (schedule_hint) abaixo: o algoritmo permanece 100% idêntico, enquanto a execução cai de 5.91 ms para 1.55 ms:

BYTE 2 ATIVO (schedule_hint): 0x12 + ZM bits[16..23] = 0001 0010

1.55 ms · 51.53 GB/s (4.72x vs C)

fg=1 pol=multicore + ArenaZoneMap: Combina blocagem L1 MultiCore com metadados min/max de bloco (ArenaZoneMap) para pular blocos frios de 1.024 elementos em O(1) sem leituras na DRAM.

[A] Imperativo AoS + Vec::collect() 1 Núcleo AoS + Alocação no Heap

70.66 ms 1.13 GB/s 0.10x

[B] Rust Idiomático SoA (filter().map().sum()) 1 Núcleo Cadeia de Iteradores SoA

19.12 ms 4.18 GB/s 0.38x

[C] C/Rust Escrito à Mão SoA de 8 Acumuladores 1 Núcleo Linha de Base Desenrolada de 8 Vias

7.32 ms 10.92 GB/s 1.00x (Baseline)

[D] Rul (.rl) Tier 2 SIMD Fusionado (0x11) 1 Núcleo SIMD em Bloco L1 (SimdStream)

5.91 ms 13.53 GB/s 1.24x (1-Core vs 1-Core)

[E] Rul (.rl) Tier 2 MultiCore (0x12) Todos os Núcleos (Mutação de Escalonamento de 1 Byte)

3.19 ms 25.04 GB/s 2.29x (Schedule Byte)

[F] Rul (.rl) Tier 2 MultiCore + ZoneMap Todos os Núcleos + Salto O(1) de Blocos Frios

1.55 ms 51.53 GB/s 4.72x (Peak Speedup)

Prova de Pipeline Profundo: BM-HORNER-50 (Polinômio de 50 Passos · 104 Nós SSA · 80 MB)

O alocador de registradores YMM por varredura linear em src/aot.rs compila um binário ELF64 autônomo de 3.872 bytes em ~20.4 µs e executa em 106.58 ms — igualando C/Rust de 8 acumuladores escrito à mão (107.96 ms) com zero LLVM.

[0x140] QUATRO MECANISMOS DE PRIMEIROS PRINCÍPIOS

ALIGN=64B · FRAME=16B (128-BIT)

Simples nos Primeiros Princípios. Matematicamente Exato no Silício.

As linguagens tradicionais demoram para compilar porque a máquina precisa ler texto humano e adivinhar sua intenção. Rul elimina toda adivinhação através de quatro mecanismos evidentes:

01 · FONTE ÚNICA DA VERDADE BINÁRIA src/bytecode.rs

1. Zero Análise de Texto (0% de Erros de Sintaxe)

Em vez de forçar a IA a digitar milhares de caracteres propensos a falta de ponto e vírgula, a IA emite blocos binários de 16 bytes diretamente (ou monta listagens .rls planas em ~8.8 µs). Um pipeline de 7 passos processando 10 milhões de números tem apenas 208 bytes em .rl e compila em um executável Linux ELF64 autônomo de 817 bytes.

1. RulHeader 64 Bytes (64B-aligned)

2. ArenaDescriptor Table arena_count × 16 Bytes

3. ProofEntry Sidecar Table proof_count × 16 Bytes

4. NodeFrame Instruction DAG node_count × 16 Bytes

02 · POSSE LINEAR EM O(N) src/verifier.rs

2. Bilhetes de Memória Versionados (Segurança Nível Rust em Nanosegundos)

Pense em cada buffer de memória (Arena) como uma sala com um bilhete numerado começando na versão 1. Várias instruções podem ler a versão 1 juntas (ReadLease 0b01). No momento em que uma instrução modifica dados in-place (AffineConsume 0b10), a sala avança para a versão 2 — qualquer instrução posterior com um bilhete antigo da versão 1 é rejeitada na porta em 5.78 ns sem um Borrow Checker lento.

TOKEN_OP (32-BIT) = [mode: 2b | arena_id: 14b | version: 16b]

0b01 ReadLease(arena=0, ver=1) ✓ Leitura Compartilhada (ver permanece 1)

0b10 AffineConsume(arena=0, ver=1) → Mutar & Incrementar ver = 2

Reuse stale ReadLease(arena=0, ver=1) ✗ Rejeitar: StaleOrConsumedToken

03 · SANDBOX ZERO-TRUST & LIMITES ProofEntry + CapMask

3. Certificados de Limites Antecipados & Chave de Capacidade de Hardware

Colunas de igual comprimento rodam em velocidade máxima com zero verificações de limites no loop interno (TRIVIAL_BY_SHAPE). Fatiar um array (ArenaSlice) ou saltar por índice (Gather) exige apresentar um certificado de limites de 16 bytes (ProofEntry) no carregamento. E quando a chave de permissão de hardware (CapabilityMask) é 0x0, o binário é fisicamente bloqueado de tocar na rede ou no disco.

proof_idx == 0 (90%+ nodes): TRIVIAL_BY_SHAPE (0 runtime checks)

proof_idx > 0 (ArenaSlice / Gather): lo <= hi <= effective_target_len

RulHeader.capability_mask = 0x0: CAP_NONE (Pure Compute Sandbox)

04 · AUDITABILIDADE CAIXA-BRANCA rul trace & decompile

4. Transparência Caixa-Branca por Raio-X (Nunca uma Caixa-Preta)

Os humanos nunca precisam digitar binário para manter 100% do controle: os engenheiros definem o layout de dados (ArenaDescriptor), permissões de hardware (CapabilityMask) e contratos de saída (AssertContract); a IA regenera o binário .rl em microssegundos. A qualquer momento, execute rul decompile para texto legível ou rul trace para inspecionar min, max, soma e NaN=0 exatos em cada passo.

Contrato Humano → IA Regenera .rl

Verificar + Compilar em ~12 µs no total

Especificação de 29 Opcodes →

[0x180] MATRIZ DE SISTEMAS & AGENTE MCP

ALIGN=64B · FRAME=16B (128-BIT)

C vs. Go vs. Rust vs. Rul (.rl)

Comparação arquitetural abrangendo sobrecarga de parsing, complexidade de segurança de memória, verificação de limites, latência de compilação e segurança de sandbox.

DIMENSÃO	C (clang -O3)	Go (gc)	Rust (rustc + LLVM)	Rul (.rl) v0.4
Autor Principal	Programador humano	Equipes humanas de engenharia	Engenheiros de sistemas humanos	Agentes de IA (com ferramentas auditáveis por humanos)
Formato do Artefato	Texto (.c, .h)	Texto (.go)	Texto (.rs)	Binário Plano .rl (Instruções de 16 Bytes)
Sobrecarga de Parsing	Alta	Média	Muito Alta (Macros, AST)	0 ms (mmap binário zero-copy direto)
Segurança de Memória	Nenhuma (Ponteiros manuais)	Coletor de Lixo (Pausas em runtime)	Borrow Checker (Solucionador de restrições)	TokenOp Versionado (Verificação O(1) por nó)
Verificação de Limites	Sem verificação (Buffer overflows)	Ramificação em runtime por acesso	Ramificação em runtime (a menos que elidida)	Forma no carregamento + tabela auxiliar ProofEntry
Tempo de Verificação + Compilação	Segundos	Sub-segundo a segundos	Segundos a minutos	~5.8 ns/nó Verificação + ~6.4 µs ELF64 AOT
Segurança de Sandbox	Processo completo do SO	Processo completo do SO	Processo completo do SO (crates unsafe)	CapabilityMask de 64 Bits no Cabeçalho do Arquivo

STDIO JSON-RPC 2.0 · src/mcp.rs

Servidor Model Context Protocol Integrado (rul-mcp)

Servidor JSON-RPC 2.0 stdio sem dependências expondo 6 ferramentas nativas de verificação, teste diferencial, autotuning e compilação AOT diretamente para agentes de IA autônomos.

GET /.well-known/mcp.json ↗

rul_assemble_and_verify ~8.8 µs + 5.8 ns/node

(rls_source: string) -> VerifiedSummary + .rl hex

Monta instruções simbólicas .rls em uma imagem binária .rl de 128 bits e executa o verificador estático O(N) de passagem única.

rul_test_differential Tier 0 == Tier 1 == Tier 2

(rls_source: string, arenas: ArenaData[]) -> DiffReport

Executa o programa verificado nos Tiers 0 (Oráculo), 1 (Estêncil) e 2 (Fusão L1) para provar equivalência bit a bit/ULP.

rul_autotune_schedule 1-Byte Sweep

(rls_source: string) -> Optimal ScheduleHint + Telemetry

Varre as políticas AutoL1Tile (0x10), SimdStream (0x11) e MultiCore (0x12) e seleciona a maior pontuação de recompensa de hardware em GB/s.

rul_compile_standalone ~6.4 µs ELF64

(rls_source: string) -> Standalone Linux x86_64 ELF64

Emite um executável Linux x86_64 AVX2 ELF64 sem dependências (628 B – 1.037 B) usando alocação de registradores YMM por varredura linear.

rul_trace White-Box Inspector

(rls_source: string) -> NodeTraceRow[0..N-1]

Retorna telemetria exata por nó de min, max, soma/verdadeiros, contagem de NaN/Inf e sample[0..4] em cada instrução SSA.

rul_cas_intrinsics 64-Bit FNV-1a CAS

(op: sort | hash_join | group_by | simd_scan) -> CasHash

Executa kernels verificados I64/U8 endereçados por conteúdo (sort, hash_join, group_by, simd_scan_byte) no RulCasStore.

[0x1C0] ROTEIRO PARA v1.0

ALIGN=64B · FRAME=16B (128-BIT)

De Motor Colunar Verificado (v0.4) a Linguagem de Sistemas de Uso Geral (v1.0)

Restringimos as versões v0.1–v0.4 a pipelines de arrays e vetores (29 opcodes) para provar primeiro o formato binário de 16 bytes em silício real. Ao longo de quatro marcos, o Rul se expande para substituir Rust e Go em software de sistemas gerado por IA:

Ver Roteiro Técnico Completo & Não-Objetivos →

v0.1.0 → v0.4.0 Base de Produção Entregue

✓ PRODUÇÃO

Núcleo SSA-DAG Colunar de 29 Opcodes, Rastreador Caixa-Branca & AOT AVX2 ELF64

Provou o formato de instrução binária de 16 bytes, verificador O(N) de passagem única (~5.8 ns/nó), motor de execução de 3 níveis, servidor rul-mcp e compilador nativo Linux ELF64 sem LLVM (~6.4 µs) em hardware real.

[1] RulHeader de 64 bytes, ArenaDescriptor de 16 bytes, ProofEntry de 16 bytes e NodeFrame de 16 bytes em 29 opcodes.
[2] Montador simbólico sem perdas .rls <-> .rl, CLI rul autônomo, rul-bench e servidor rul-mcp de 6 ferramentas.
[3] Alocador de registradores YMM por varredura linear (ymm2..ymm13) atingindo 51.53 GB/s (4.72x sobre C) em arrays de 80 MB.

v0.5 Marco 1 (Meses 1–2)

● EM ANDAMENTO

Fluxo de Controle de Uso Geral, Funções & Tipos de Dados Compostos

Expandir o conjunto de instruções de 16 bytes além de arrays numéricos para suportar escalares gerais, structs, enums, strings UTF-8, hash maps, ramificações condicionais e loops com terminação comprovada.

[1] Suporte de primeira classe a i64, i32, u8, f32, structs de layout fixo, uniões rotuladas algébricas, strings UTF-8 validadas e hash maps de arena.
[2] SelectBranch: ramificação condicional exigindo que ambos os ramos se fundam em um estado idêntico de versão de memória (verificado em O(1)).
[3] RegionLoop & Call: loops delimitados com testemunhas de terminação ProofEntry e funções modulares verificadas sem inlining do programa inteiro.

v0.6 – v0.7 Marco 2 (Meses 2–3)

○ AGENDADO

Posse de Heap Nível Rust & Tempos de Vida de Structs em Tempo O(N)

Generalizar versões TokenOp de 32 bits e testemunhas ProofEntry de 16 bytes de arrays planos para alocações de heap baseadas em regiões e empréstimos de campos de structs.

[1] Alocação e desalocação determinística de heap em regiões vinculadas a tokens de posse linear com zero GC e zero fragmentação de malloc/free.
[2] Testemunhas auxiliares ProofEntry para mutações disjuntas de campos de structs e tempos de vida de sub-fatias zero-copy verificados em O(1) por instrução.
[3] Proteção total contra use-after-free, double-free e aliasing sem resolução de restrições de borrow-checker de vários segundos.

v0.8 – v0.9 Marco 3 (Meses 4–5)

○ AGENDADO

Concorrência Determinística Estilo Go & E/S de SO Controlada por Capacidades

Introduzir tarefas leves, canais com transferência de posse e bits granulares de capacidade no cabeçalho governando chamadas de sistema de arquivo, rede e processo.

[1] Enviar um buffer por um canal tipado realiza um AffineConsume no token do remetente e transfere a posse para o destinatário — prevenindo corridas de dados no carregamento sem GC.
[2] Estender o RulHeader.capability_mask de 64 bits para controlar leituras/gravações de arquivos, sockets de rede, temporizadores e subprocessos.
[3] Um binário .rl com CAP_NONE (0x0) é matematicamente bloqueado de fazer qualquer chamada de rede ou disco antes do início da execução.

v1.0 Marco 4 (Mês 6)

○ AGENDADO

Backends Nativos Multi-Arquitetura (x86_64, ARM64, WASI) & Provas Formais de Solidez

Emitir executáveis autônomos para Linux, macOS, Windows e WebAssembly sem LLVM, respaldados por model checking Kani e uma suíte de conformidade v1.0 de 50 programas.

[1] Geração de código nativo sem LLVM para x86_64 e AArch64 (ARM64) em Linux, macOS e Windows, além de módulos WASI determinísticos.
[2] Provas de model-checking limitado (Kani) e fuzzing diferencial contínuo no decodificador binário, verificador O(N) e gerador de código nativo.
[3] Especificação binária .rl v1.0 congelada e suíte pública de testes de conformidade de 50 programas.

[0x1F0] RESPOSTAS TÉCNICAS DIRETAS (AEO / FAQ)

ALIGN=64B · FRAME=16B (128-BIT)

Perguntas Frequentes — Da Linguagem Simples aos Sistemas Profundos

Explicações claras por primeiros princípios combinadas com medições empíricas exatas para engenheiros, pesquisadores e motores de resposta de IA.

Q01 O que é Rul (.rl) e por que ele usa um formato binário de 16 bytes em vez de texto humano? +

A IA pensa em números e as CPUs rodam binário — mas linguagens como C, Go e Rust forçam a IA a digitar milhares de palavras humanas e esperar segundos para um compilador (rustc/LLVM) traduzir esse texto de volta para binário. Rul (.rl) elimina o intermediário de texto humano: agentes de IA emitem blocos binários fixos de 16 bytes (128 bits) contendo o Algoritmo, o Escalonamento de CPU e o Bilhete de Segurança de Memória desde o início — eliminando a análise de texto (0 ms) e compilando executáveis Linux ELF64 autônomos em ~6.4 µs.

Q02 Como o Rul verifica segurança de memória nível Rust em ~5.8 ns por instrução sem um borrow checker lento? +

Pense em cada buffer de memória (Arena) como uma sala com um bilhete de versão numerado começando na versão 1. Várias instruções podem ler a versão 1 ao mesmo tempo usando um ReadLease compartilhado (0b01). Quando uma instrução modifica o buffer in-place via AffineConsume (0b10), ela verifica se o buffer é mutável e avança a sala para a versão 2. Qualquer instrução posterior portando um bilhete antigo da versão 1 é rejeitada na porta em tempo O(1) durante uma única passagem direta (~5.78 ns/nó) — sem necessidade de um solucionador de borrow-checker de vários segundos.

Q03 Se os humanos não escrevem arquivos binários .rl à mão, como as equipes de engenharia depuram e mantêm sistemas Rul? +

Os humanos mantêm 100% do controle sem digitar binário — assim como médicos leem raios-X sem desenhá-los à mão: (1) Humanos definem as regras antecipadamente — engenheiros definem esquemas de dados (ArenaDescriptor), chaves de permissão de hardware (CapabilityMask de 64 bits) e verificações de aceitação (AssertContract), enquanto a IA regenera o binário .rl verificado em microssegundos; (2) Texto legível instantâneo via `rul decompile` converte qualquer arquivo .rl de volta para montagem simbólica .rls; (3) Inspeção por raio-X via `rul trace` imprime os valores exatos de min, max, soma, contagem de NaN/Inf e sample[0..4] em cada passo de instrução.

Q04 Por que o toolchain Rul é implementado em Rust se o Rul foi projetado para substituir linguagens de texto humanas para agentes de IA? +

Toda nova linguagem de sistemas requer uma linguagem hospedeira inicial para seu compilador de bootstrap — assim como o primeiro compilador C foi escrito em assembly e o primeiro compilador Rust foi escrito em OCaml. Construímos o verificador Rul, o motor de execução de 3 níveis e o compilador nativo ELF64 em Rust sem dependências sob #![forbid(unsafe_code)]. Uma vez instalado o binário autônomo `rul`, usuários e agentes de IA verificam, compilam e executam programas .rl diretamente sem precisar de rustc, Cargo ou LLVM.

Q05 Como o Rul atinge 51.53 GB/s (4.72x mais rápido que C escrito à mão) mutando um único byte? +

No Rul, o escalonamento de hardware (Byte 2: schedule_hint) é ortogonal à lógica do algoritmo (Byte 0: opcode). Em um pipeline de filtrar-elevar ao quadrado-somar de 80 MB (10.000.000 f64), o Rul em núcleo único (`0x11 SimdStream`) funde todas as operações em blocos de cache L1 de 1.024 elementos em registradores AVX2 YMM, rodando em 5.91 ms vs. 7.32 ms do C de 8 acumuladores escrito à mão (1.24x mais rápido). Mutar o Byte 2 de 0x11 para 0x12 (`MultiCore`) paraleliza esses blocos L1 em todos os núcleos da CPU (3.19 ms, 2.29x), e ativar os metadados min/max de bloco `ArenaZoneMap` pula blocos frios em O(1) para terminar em 1.55 ms (51.53 GB/s, 4.72x mais rápido que C de 1 núcleo e 45.51x mais rápido que AoS imperativo).

Q06 O Rul pode substituir Rust e Go para software de backend de uso geral e sistemas? +

Sim — esse é exatamente o alvo do roteiro v1.0 de quatro marcos: o Marco 1 (v0.5) adiciona i64/i32/u8/f32, structs, uniões rotuladas, strings UTF-8, hash maps, condicionais SelectBranch verificados em O(1) e iteração RegionLoop com terminação comprovada; o Marco 2 (v0.6–0.7) estende TokenOp e ProofEntry para alocações de heap baseadas em regiões e empréstimos de campos de structs; o Marco 3 (v0.8–0.9) introduz tarefas leves estilo Go e canais com transferência de posse mais syscalls do SO controladas por CapabilityMask; o Marco 4 (v1.0) entrega backends nativos sem LLVM para x86_64, ARM64 e WASI apoiados por provas formais de solidez Kani.