[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · 128-Bit-Binär-IR

Die 128-Bit-Binäre Programmiersprache für KI-Agenten.

KI denkt in Zahlen und CPUs verarbeiten Binärcode — doch C, Go und Rust zwingen KI, menschlichen Text zu tippen und Sekunden zu warten, bis ein Compiler die Absicht errät. Rul (.rl) streicht diesen Text-Vermittler: KI erzeugt feste 16-Byte-Binärblöcke mit Algorithmus, CPU-Zeitplan und Speichersicherheitsticket von Anfang an. Ergebnis: 5,8 ns Sicherheitsprüfung, 6,4 µs eigenständige Kompilierung und 4,72x schnellere Ausführung als handgeschriebenes C.

FIRST-PRINCIPLES IN 10 SEKUNDEN · TEXT-VERMITTLER STREICHEN

✗ ALTER WEG (C / Go / Rust) KI denkt (Zahlen) → Tippt Text → Compiler parst & rät Absicht (Sekunden) → Maschinencode (0/1)

✓ RUL (.rl) FIRST-PRINCIPLES KI denkt (Zahlen) → Erzeugt 16-Byte-Binärblock (5,8 ns Beweis + 6,4 µs Kompilierung) → 4,72x schneller als C

16-Byte-Binärblock (0ms Text-Parsing) + 6,4 µs Natives ELF64 (Ohne LLVM) + 5,8 ns Sicherheitsbeweis (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)

16-Byte-Frame untersuchen ↓ v0.4 Spezifikation Whitepaper (DOI) ↗

LIVE .RL-BINÄRABBILD · 7 SSA-KNOTEN = 208 BYTES -> 817-BYTE ELF64 CAP_NONE=0x0

Klicken Sie unten auf einen 16-Byte-Befehlsrahmen, um Bits, Sicherheitsbeweis und Trace zu dekodieren:

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] 128-Bit-Frame

16 Bytes

Jeder Befehl ist ein fester Binärbaustein · 0 ms Text-Parsing

[0x50] pro Befehl

5,78 ns

Sofortiger Speicher- & Grenzbeweis (Einziger O(N)-Durchlauf)

[0x60] native Kompilierung

6,4 µs

Eigenständige Linux x86_64 ELF64-Binärdatei ohne LLVM

[0x70] 4,72x ggü. C

51,53 GB/s

10 Mio. Zahlen (80 MB) beschleunigt durch 1-Byte-Mutation

[0x80] INTERAKTIVE 128-BIT-WERKBANK

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

Ein 16-Byte-Befehl = Algorithmus + Zeitplan + Beweis

Wählen Sie einen Befehlsknoten (#0..#6) oder klicken Sie auf ein Byte (0..15), um das 8-Bit-Register, die O(N)-Verifikationsregel und den Live-White-Box-Trace zu prüfen.

Algorithmus-Spur (Was berechnen: Opcode / Operanden) Zeitplan-Spur (Wie ausführen: SIMD / MultiCore) Beweis-Spur (Sicherheit: Versionsticket / Grenzen)

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

16 BYTES = 128 BITS

8-BIT-REGISTERAUFSCHLÜSSELUNG · 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

Feld: schedule_hint Typ: u8

✓ Beim Laden geprüfte O(N)-Verifizierer-Invariante (~5.78 ns) (fusion_group << 4) | exec_policy

Orthogonales Hardware-Zeitplan-Byte: Mutation von 0x11 (SimdStream) -> 0x12 (MultiCore) ändert die CPU-Ausführung ohne Änderung der Sicherheitsbeweise.

Knoten #3: Elementweises 8-Spur-Vektorquadrat ($n0 * $n0), verschmolzen in L1-Cache-Registern ohne Zwischen-Heap-Allokation.

Symbolische Assembler-Ansicht (src/main.rls — 208 B in .rl) ~8.8 µs assemble

cap 0x0

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

output $n6

White-Box-Ausführungs-Tracer (rul trace — 7 SSA-Knoten) Zeile anklicken, um 16-Byte-Binärframe & Assembler zu synchronisieren

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] 1-BYTE-HARDWARE-ZEITPLAN-MUTATION

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

1 Byte ändern (Byte 2). 4,72x schneller als handgeschriebenes C.

Reale Arbeitslast: 10.000.000 Gleitkommazahlen (80-MB-Array) — Werte > 1000.0 filtern, quadrieren und summieren. Klicken Sie unten, um Byte 2 (schedule_hint) zu ändern: Der Algorithmus bleibt zu 100 % identisch, die Laufzeit sinkt von 5,91 ms auf 1,55 ms:

AKTIVES BYTE 2 (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: Kombiniert MultiCore-L1-Tiling mit Block-Min/Max-Metadaten (ArenaZoneMap), um kalte 1.024-Elemente-Kacheln in O(1) ohne DRAM-Lesezugriff zu überspringen.

[A] Imperatives AoS + Vec::collect() 1-Kern AoS + Heap-Allokation

70.66 ms 1.13 GB/s 0.10x

[B] Idiomatisches Rust SoA (filter().map().sum()) 1-Kern SoA-Iteratorkette

19.12 ms 4.18 GB/s 0.38x

[C] Handgeschriebenes C/Rust 8-Akkumulator SoA 1-Kern 8-Spur-Unrolled-Baseline

7.32 ms 10.92 GB/s 1.00x (Baseline)

[D] Rul (.rl) Tier 2 Verschmolzenes SIMD (0x11) 1-Kern L1-Kachel-SIMD (SimdStream)

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

[E] Rul (.rl) Tier 2 MultiCore (0x12) Alle Kerne (1-Byte-Zeitplan-Mutation)

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

[F] Rul (.rl) Tier 2 MultiCore + ZoneMap Alle Kerne + O(1) Überspringen kalter Kacheln

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

Tiefer Pipeline-Beweis: BM-HORNER-50 (50-stufiges Polynom · 104 SSA-Knoten · 80 MB)

Der Linear-Scan-YMM-Registerallokator in src/aot.rs kompiliert ein 3.872 Byte großes ELF64-Binary in ~20,4 µs und führt es in 106,58 ms aus — auf Augenhöhe mit handgeschriebenem 8-Akkumulator-C/Rust (107,96 ms) ganz ohne LLVM.

[0x140] VIER FIRST-PRINCIPLES-MECHANISMEN

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

Einfach in den Grundprinzipien. Mathematisch exakt im Silizium.

Traditionelle Sprachen kompilieren langsam, weil die Maschine menschlichen Text lesen und Ihre Absicht erraten muss. Rul beseitigt jedes Raten durch vier selbsterklärende Mechanismen:

01 · BINÄRCODE ALS EINZIGE QUELLE DER WAHRHEIT src/bytecode.rs

1. Null Text-Parsing (0 % Syntaxfehler)

Anstatt KI tausende Zeichen tippen zu lassen, bei denen Semikolons fehlen können, erzeugt KI direkt 16-Byte-Binärbausteine (oder assembliert .rls in ~8,8 µs). Eine 7-stufige Pipeline für 10 Millionen Zahlen ist in .rl nur 208 Bytes groß und kompiliert zu einer eigenständigen 817-Byte-Linux-ELF64-Datei.

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 · LINEARES EIGENTUM IN O(N) src/verifier.rs

2. Versionierte Speichertickets (Rust-Sicherheit in Nanosekunden)

Stellen Sie sich jeden Speicherpuffer (Arena) wie einen Raum mit einem Ticket ab Version 1 vor. Mehrere Befehle können Version 1 gleichzeitig lesen (ReadLease 0b01). Sobald ein Befehl Daten vor Ort ändert (AffineConsume 0b10), steigt der Raum auf Version 2 — jeder spätere Befehl mit einem alten Version-1-Ticket wird in 5,78 ns an der Tür abgewiesen, ganz ohne langsamen Borrow Checker.

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

0b01 ReadLease(arena=0, ver=1) ✓ Geteiltes Lesen (Version bleibt 1)

0b10 AffineConsume(arena=0, ver=1) → Vor-Ort-Mutation & Version = 2

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

03 · ZERO-TRUST-SANDBOX & GRENZEN ProofEntry + CapMask

3. Vorab-Grenzzertifikate & Hardware-Rechteschalter

Gleich lange Spalten laufen mit voller Geschwindigkeit ohne Grenzprüfungen in der Schleife (TRIVIAL_BY_SHAPE). Das Schneiden eines Arrays (ArenaSlice) oder Index-Zugriffe (Gather) erfordern beim Laden ein 16-Byte-Grenzzertifikat (ProofEntry). Und wenn der Hardware-Rechteschalter (CapabilityMask) 0x0 ist, ist das Programm physisch vom Netzwerk oder Datenträger getrennt.

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 · WHITE-BOX-PRÜFBARKEIT rul trace & decompile

4. Röntgen-White-Box-Transparenz (Niemals eine Blackbox)

Menschen müssen keinen Binärcode tippen, um 100 % Kontrolle zu behalten: Ingenieure legen Datenlayout (ArenaDescriptor), Hardware-Rechte (CapabilityMask) und Ausgabeverträge (AssertContract) fest; die KI regeneriert das .rl-Binary in Mikrosekunden. Jederzeit liefert rul decompile lesbaren Text oder rul trace exakte Min-, Max-, Summen- und NaN=0-Werte für jeden Schritt.

Menschlicher Vertrag → KI generiert .rl neu

Prüfung + Kompilierung in ~12 µs gesamt

29-Opcode-Spezifikation →

[0x180] SYSTEMMATRIX & AGENT MCP

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

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

Architekturvergleich hinsichtlich Parsing-Overhead, Speichersicherheit, Grenzprüfungen, Kompilierungslatenz und Sandbox-Sicherheit.

KRITERIUM	C (clang -O3)	Go (gc)	Rust (rustc + LLVM)	Rul (.rl) v0.4
Primärer Autor	Menschlicher Programmierer	Menschliche Entwicklerteams	Menschliche Systemingenieure	KI-Agenten (mit prüfbaren White-Box-Werkzeugen)
Artefaktformat	Text (.c, .h)	Text (.go)	Text (.rs)	Flaches Binärformat .rl (16-Byte-Befehle)
Parsing-Overhead	Hoch	Mittel	Sehr hoch (Makros, AST)	0 ms (Direktes Zero-Copy-Binär-mmap)
Speichersicherheit	Keine (Manuelle Zeiger)	Garbage Collector (Laufzeitpausen)	Borrow Checker (Constraint-Solver)	Versioniertes TokenOp (O(1)-Prüfung pro Knoten)
Array-Grenzprüfung	Ungeprüft (Pufferüberläufe)	Laufzeitverzweigung pro Zugriff	Laufzeitverzweigung (sofern nicht eliminiert)	Prüfung beim Laden über Shape + ProofEntry-Tabelle
Prüf- + Kompilierzeit	Sekunden	Subsekunden bis Sekunden	Sekunden bis Minuten	~5,8 ns/Knoten Prüfung + ~6,4 µs ELF64 AOT
Sandbox-Sicherheit	Volle OS-Prozessrechte	Volle OS-Prozessrechte	Volle OS-Prozessrechte (unsafe Crates)	64-Bit-CapabilityMask direkt im Dateiheader

STDIO JSON-RPC 2.0 · src/mcp.rs

Integrierter Model Context Protocol Server (rul-mcp)

Abhängigkeitsfreier stdio JSON-RPC 2.0-Server, der autonomen KI-Agenten 6 native Werkzeuge für Verifikation, Differenztests, Autotuning und AOT-Kompilierung bereitstellt.

GET /.well-known/mcp.json ↗

rul_assemble_and_verify ~8.8 µs + 5.8 ns/node

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

Assembliert symbolische .rls-Befehle in ein 128-Bit-.rl-Binärabbild und führt den linearen O(N)-Statikverifizierer aus.

rul_test_differential Tier 0 == Tier 1 == Tier 2

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

Führt das verifizierte Programm über Tier 0 (Oracle), Tier 1 (Stencil) und Tier 2 (L1 Fused) aus, um bitweise/ULP-Äquivalenz zu beweisen.

rul_autotune_schedule 1-Byte Sweep

(rls_source: string) -> Optimal ScheduleHint + Telemetry

Testet die Richtlinien AutoL1Tile (0x10), SimdStream (0x11) und MultiCore (0x12) und wählt den höchsten GB/s-Hardware-Durchsatz.

rul_compile_standalone ~6.4 µs ELF64

(rls_source: string) -> Standalone Linux x86_64 ELF64

Erzeugt eine abhängigkeitsfreie Linux x86_64 AVX2 ELF64-Binärdatei (628 B – 1.037 B) mittels Linear-Scan-YMM-Registerallokation.

rul_trace White-Box Inspector

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

Liefert exakte Min-, Max-, Summen-/Wahr-Werte, NaN/Inf-Zähler und sample[0..4]-Telemetrie für jeden SSA-Befehlsknoten.

rul_cas_intrinsics 64-Bit FNV-1a CAS

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

Führt verifizierte inhaltsadressierte I64/U8-Kerne (sort, hash_join, group_by, simd_scan_byte) im RulCasStore aus.

[0x1C0] ROADMAP ZU v1.0

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

Von der verifizierten Spalten-Engine (v0.4) zur allgemeinen Systemsprache (v1.0)

Wir haben v0.1–v0.4 bewusst auf Array- und Vektor-Pipelines (29 Opcodes) beschränkt, um das 16-Byte-Binärformat zuerst auf echter Hardware zu beweisen. Über vier Meilensteine wächst Rul zum Ersatz für Rust und Go heran:

Vollständige technische Roadmap & Nicht-Ziele ansehen →

v0.1.0 → v0.4.0 Ausgelieferte Produktionsbasis

✓ PRODUKTIV

29-Opcode-Spalten-SSA-DAG-Kern, White-Box-Tracer & Linear-Scan AVX2 ELF64 AOT

Bewies das 16-Byte-Binärbefehlsformat, den linearen O(N)-Verifizierer (~5,8 ns/Knoten), die 3-stufige Ausführungs-Engine, den rul-mcp-Server und den LLVM-freien Linux-ELF64-Compiler (~6,4 µs) auf realer Hardware.

[1] 64-Byte-RulHeader, 16-Byte-ArenaDescriptor, 16-Byte-ProofEntry und 16-Byte-NodeFrame über 29 Opcodes.
[2] Verlustfreier symbolischer .rls <-> .rl Assembler, eigenständige rul-CLI, rul-bench und 6-Tool-rul-mcp-Server.
[3] Linear-Scan-YMM-Registerallokator (ymm2..ymm13) mit 51,53 GB/s (4,72x schneller als C) auf 80-MB-Arrays.

v0.5 Meilenstein 1 (Monate 1–2)

● IN ARBEIT

Allgemeiner Kontrollfluss, Funktionen & zusammengesetzte Datentypen

Erweiterung des 16-Byte-Befehlssatzes über numerische Arrays hinaus auf Skalare, Structs, Enums, UTF-8-Strings, Hash-Maps, Verzweigungen und terminierungsbewiesene Schleifen.

[1] Erstklassige Unterstützung für i64, i32, u8, f32, Structs mit festem Layout, algebraische Unions, validierte UTF-8-Strings und Arena-Hash-Maps.
[2] SelectBranch: bedingte Verzweigung, bei der beide Zweige im identischen Speicherversionszustand zusammenlaufen müssen (geprüft in O(1)).
[3] RegionLoop & Call: begrenzte Schleifen mit ProofEntry-Terminierungszeugen und modulare Funktionen ohne Ganzprogramm-Inlining.

v0.6 – v0.7 Meilenstein 2 (Monate 2–3)

○ GEPLANT

Heap-Eigentum auf Rust-Niveau & Struct-Lebensdauern in O(N)-Zeit

Verallgemeinerung der 32-Bit-TokenOp-Versionen und 16-Byte-ProofEntry-Zeugen von flachen Arrays auf regionsbasierte Heap-Allokationen und Struct-Feld-Borrows.

[1] Deterministische Regions-Heap-Allokation und -Freigabe gebunden an lineare Eigentumstokens ohne GC und ohne malloc/free-Fragmentierung.
[2] ProofEntry-Zeugen für disjunkte Struct-Feld-Mutationen und Zero-Copy-Sub-Slice-Lebensdauern, geprüft in O(1) pro Befehl.
[3] Voller Schutz gegen Use-after-Free, Double-Free und Aliasing ohne sekundenlanges Borrow-Checker-Constraint-Solving.

v0.8 – v0.9 Meilenstein 3 (Monate 4–5)

○ GEPLANT

Deterministische Nebenläufigkeit im Go-Stil & CapabilityMask-gesteuerte OS-I/O

Einführung leichtgewichtiger Tasks, eigentumsübertragender Kanäle und feingranularer Header-Capability-Bits für Datei-, Netzwerk- und Prozess-Syscalls.

[1] Das Senden eines Puffers über einen typisierten Kanal führt ein AffineConsume beim Sender durch und überträgt das Eigentum an den Empfänger — verhindert Data Races beim Laden ohne GC.
[2] Erweiterung der 64-Bit-RulHeader.capability_mask zur Steuerung von Dateisystemzugriffen, Netzwerksockets, Timern und Unterprozessen.
[3] Ein .rl-Binary mit CAP_NONE (0x0) ist mathematisch vor Ausführungsbeginn daran gehindert, Netzwerk- oder Festplattenaufrufe zu tätigen.

v1.0 Meilenstein 4 (Monat 6)

○ GEPLANT

Multi-Architektur-Native-Backends (x86_64, ARM64, WASI) & Formale Korrektheitsbeweise

Erzeugung eigenständiger Binärdateien für Linux, macOS, Windows und WebAssembly ohne LLVM, abgesichert durch Kani-Model-Checking und eine 50-Programme-Konformitätssuite.

[1] LLVM-freie native Codegenerierung für x86_64 und AArch64 (ARM64) unter Linux, macOS und Windows sowie deterministische WASI-Module.
[2] Bounded-Model-Checking-Beweise (Kani) und kontinuierliches differentielles Fuzzing über Binärdecoder, O(N)-Verifizierer und Codegen.
[3] Eingefrorene .rl v1.0-Binärspezifikation und öffentliche 50-Programme-Konformitätstestsuite.

[0x1F0] DIREKTE TECHNISCHE ANTWORTEN (AEO / FAQ)

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

Häufig gestellte Fragen — Von einfachen Grundlagen bis zur Systemtiefe

Klare First-Principles-Erklärungen gepaart mit exakten empirischen Messwerten für Ingenieure, Forscher und KI-Antwortmaschinen.

Q01 Was ist Rul (.rl) und warum verwendet es ein 16-Byte-Binärformat statt menschlichem Text? +

KI denkt in Zahlen und CPUs führen Binärcode aus — doch Sprachen wie C, Go und Rust zwingen KI dazu, tausende menschliche Wörter zu tippen und Sekunden zu warten, bis ein Compiler (rustc/LLVM) diesen Text wieder in Binärcode übersetzt. Rul (.rl) streicht den menschlichen Text-Vermittler: KI-Agenten erzeugen feste 16-Byte (128-Bit) Binärbausteine, die Algorithmus, CPU-Zeitplan und Speichersicherheitsticket direkt enthalten — das reduziert das Text-Parsing auf 0 ms und kompiliert eigenständige Linux-ELF64-Binärdateien in ~6,4 µs.

Q02 Wie prüft Rul Speichersicherheit auf Rust-Niveau in ~5,8 ns pro Befehl ohne langsamen Borrow Checker? +

Stellen Sie sich jeden Speicherpuffer (Arena) wie einen Raum mit einem nummerierten Versionsticket ab Version 1 vor. Mehrere Befehle können Version 1 gleichzeitig über ein geteiltes ReadLease (0b01) lesen. Wenn ein Befehl den Puffer vor Ort über AffineConsume (0b10) ändert, prüft er die Änderbarkeit und erhöht den Raum auf Version 2. Jeder spätere Befehl mit einem veralteten Version-1-Ticket wird in einem einzigen Vorwärtsdurchlauf (~5,78 ns/Knoten) in O(1)-Zeit an der Tür abgewiesen — ganz ohne mehrsekündigen Borrow-Checker-Solver.

Q03 Wenn Menschen .rl-Binärdateien nicht von Hand schreiben, wie debuggen und warten Entwicklerteams Rul-Systeme? +

Menschen behalten zu 100 % die Kontrolle, ohne Binärcode zu tippen — genau wie Ärzte Röntgenbilder lesen, ohne sie von Hand zu zeichnen: (1) Menschen legen vorab die Regeln fest — Ingenieure definieren Datenschemata (ArenaDescriptor), Hardware-Rechteschalter (64-Bit-CapabilityMask) und Abnahmeprüfungen (AssertContract), während die KI das verifizierte .rl-Binary in Mikrosekunden neu erzeugt; (2) Sofort lesbarer Text über `rul decompile` wandelt jede .rl-Datei verlustfrei in symbolischen `.rls`-Assembler um; (3) Röntgen-Inspektion über `rul trace` gibt für jeden Befehlsschritt exakte Min-, Max-, Summen-, NaN/Inf-Werte und sample[0..4] aus.

Q04 Warum ist die Rul-Toolchain in Rust implementiert, wenn Rul menschliche Textsprachen für KI-Agenten ersetzen soll? +

Jede neue Systemsprache benötigt eine initiale Host-Sprache für ihren ersten Bootstrap-Compiler — genau wie der erste C-Compiler in Assembler und der erste Rust-Compiler in OCaml geschrieben wurde. Wir haben den Rul-Verifizierer, die 3-stufige Ausführungs-Engine und den nativen ELF64-Compiler in abhängigkeitsfreiem Rust unter `#![forbid(unsafe_code)]` entwickelt. Sobald das eigenständige `rul`-Binary installiert ist, verifizieren, kompilieren und starten Nutzer und KI-Agenten `.rl`-Programme direkt ohne rustc, Cargo oder LLVM.

Q05 Wie erreicht Rul 51,53 GB/s (4,72x schneller als handgeschriebenes C) durch die Änderung eines einzigen Bytes? +

In Rul ist die Hardware-Zeitplanung (Byte 2: schedule_hint) vollkommen unabhängig von der Algorithmuslogik (Byte 0: opcode). Bei einer 80-MB-Filter-Quadrat-Summen-Pipeline (10.000.000 f64) verschmilzt Rul auf einem Kern (`0x11 SimdStream`) alle Operationen in 1.024-Elemente-L1-Cache-Kacheln in AVX2-YMM-Registern und läuft in 5,91 ms gegenüber 7,32 ms für handgeschriebenes 8-Akkumulator-C (1,24x schneller). Die Mutation von Byte 2 von 0x11 auf 0x12 (`MultiCore`) parallelisiert diese L1-Kacheln über alle CPU-Kerne (3,19 ms, 2,29x), und das Aktivieren der `ArenaZoneMap`-Block-Min/Max-Metadaten überspringt kalte Kacheln in O(1), sodass die Berechnung in 1,55 ms abgeschlossen wird (51,53 GB/s, 4,72x schneller als 1-Kern-C und 45,51x schneller als imperatives AoS).

Q06 Kann Rul Rust und Go für allgemeine Backend- und Systemsoftware ersetzen? +

Ja — genau das ist das Ziel der vierstufigen v1.0-Roadmap: Meilenstein 1 (v0.5) ergänzt i64/i32/u8/f32, Structs, Tagged Unions, UTF-8-Strings, Hash-Maps, O(1)-geprüfte SelectBranch-Verzweigungen und terminierungsbewiesene RegionLoop-Schleifen; Meilenstein 2 (v0.6–0.7) erweitert TokenOp und ProofEntry auf regionsbasierte Heap-Allokationen und Struct-Feld-Borrows; Meilenstein 3 (v0.8–0.9) führt leichtgewichtige Tasks und eigentumsübertragende Kanäle im Go-Stil sowie feingranulare CapabilityMask-OS-Syscalls ein; Meilenstein 4 (v1.0) liefert LLVM-freie native Backends für x86_64, ARM64 und WASI, abgesichert durch formale Kani-Korrektheitsbeweise.