Lyx OS – LBF: Lyx Binary Format

Das Lyx Binary Format (LBF) ist das native ausführbare Binärformat von Lyx OS. Es ersetzt ELF/PE für alle Programme die mit lyxc –target=lyxos kompiliert werden, und ist von Grund auf für KI-native Architekturen und das Island & Ocean File System (IOFS) entworfen.

Version: 1.1 · Magic: LYX! (0x4C 0x59 0x58 0x21)

→ Anwendungen entwickeln · Kernel-Interna · Übersicht

ELF und PE tragen jahrzehntelangen Ballast: komplexe Relokationstabellen, dynamische Linker, Sektions-Parsing zur Laufzeit — und keinerlei semantische Selbstbeschreibung. LBF bricht damit auf drei Ebenen:

Physisch: LBF ist exakt auf das 4096-Byte-Page-Raster der NVMe-Hardware und der CPU ausgerichtet. Auf nativem IOFS lädt der Kernel keine Segmente in den RAM — er trägt die physischen Sektoradressen (LBAs) direkt in die Page Tables (CR3) ein. Die CPU feuert den Maschinencode ohne eine einzige Kopie.

Semantisch: Block 0 (der Genesis-Block) enthält einen strukturierten KI-Kontext-Pool, der der System-KI vor der ersten Ausführung mitteilt: was das Programm tut, welche Hardware-Erweiterungen es benötigt, welche Abhängigkeiten es deklariert, und ob die kryptografische Vertrauenskette intakt ist.

Dual-Portabel: Auf Legacy-Dateisystemen verhält sich LBF wie eine flache, sequentielle Binärdatei (POSIX-Loader lbf_run). Auf nativem IOFS injiziert der Kernel die 4-KB-Blöcke direkt als Datenknoten in den Graphen. Dasselbe Binary, zwei Lademodi, null Overhead.

Jede logische Sektion (.text, .data, .rodata) beginnt an einer physischen 4096-Byte-Grenze. Optimal für große, monolithische Anwendungen: maximale Page-Table-Mapping-Performance, jeder Block direkt als IOFS-Page importierbar.

Block 0:  Genesis-Block (4096 Bytes)
Block 1:  .text [0]
Block 2:  .text [1]
Block 3:  .rodata [0]   ← neue 4-KB-Grenze, eigene Page
Block 4:  .data [0]     ← neue 4-KB-Grenze, eigene Page

Für Kleinstprogramme und Microservices. Sektionen mit identischen Zugriffsrechten werden in dieselbe 4-KB-Page gepackt. Erst wenn sich die Schutzrechte ändern, beginnt ein neuer Block.

Packing-Regel: .text (R/X) und .rodata (R) können in eine gemeinsame Page. .data (R/W) erzwingt immer eine neue 4-KB-Grenze.

Block 0:  Genesis-Block (4096 Bytes)
Block 1:  .text + .rodata zusammen (beide R, ≤ 4032 Bytes)
Block 2:  .data [0]     ← Grenze wegen R/W

Der Compiler setzt lbf_flags |= LBF_FLAGS_PACKED im Genesis-Header. Der Loader (POSIX und IOFS) liest dieses Bit und wendet die korrekten Schutzrechte anhand des Section-Descriptor-TLV (Typ 0x08) pro Sub-Segment an.

Block 0 ist das vollständige Kontrollzentrum: 96-Byte-Header gefolgt von einem 4000-Byte-TLV-Pool.

┌─────────────────────────────────────────────────────────────────┐
│  0x0000–0x000F  Core Machine Header          (16 Bytes)         │
│  0x0010–0x005B  Compiler Provenance Block    (76 Bytes)         │
│  0x005C–0x005F  Layout Flags & KI-Offset     (4 Bytes)          │
├─────────────────────────────────────────────────────────────────┤
│  0x0060–0x0FFF  KI-Semantik-Register / TLV-Pool (4000 Bytes)   │
└─────────────────────────────────────────────────────────────────┘

con LBF_FLAGS_PACKED : uint16 := 1

con LBF_ARCH_X86_64  : uint8 := 0x01
con LBF_ARCH_ARM64   : uint8 := 0x02
con LBF_ARCH_RISCV   : uint8 := 0x03

Block 0 folgen die Code- und Daten-Blöcke. Jeder Block ist exakt 4096 Bytes, ohne eigenen Block-Header.

BLOCK 0    Genesis-Block
BLOCK 1+   .text [0..N]    R/X — Maschinencode
BLOCK N+1  .rodata [0..]   R   — Konstanten, String-Literale
BLOCK M+1  .data [0..]     R/W — initialisierte globale Variablen
BLOCK K+1  .bss             R/W — Kernel setzt auf 0, kein Inhalt auf Disk

Im Modus B können .text + .rodata in einem gemeinsamen Block stehen; die Aufteilung steht im Section-Descriptor-TLV (Typ 0x08).

Der 4000-Byte-Pool ab Offset 0x0060 verwendet eine Type-Length-Value-Struktur:

[Type: uint8 (1 Byte)] [Length: uint16 LE (2 Bytes)] [Value: Length Bytes]
Overhead pro Eintrag: 3 Bytes

Reichen 4000 Bytes nicht aus, verweist TLV 0x05 (EXT_META_PTR) auf eine Continuation-IOFS-Page. Das Framework ist damit für beliebig komplexe Programme unbegrenzt erweiterbar.

Payload: UTF-8-Freitext, max. 512 Bytes.

Enthält die semantische Beschreibung des Programms. Der Compiler extrahiert ihn aus /‑Doc-Comments über main():

/// Berechnet die CRC32C-Prüfsumme für Speichermedien im IOFS.
/// Liest Eingabe von stdin, gibt Prüfsumme als Hex auf stdout aus.
fn main(): int64 { ... }

con LBF_ISA_AVX2    : uint64 := 1    // Intel AVX2 (256-bit SIMD)
con LBF_ISA_AVX512  : uint64 := 2    // Intel AVX-512 (512-bit SIMD)
con LBF_ISA_ARM_NEON: uint64 := 4    // ARM NEON / AdvSIMD
con LBF_ISA_AMX     : uint64 := 8    // Intel AMX (KI-Beschleunigung)
con LBF_ISA_SVE     : uint64 := 16   // ARM SVE/SVE2
con LBF_ISA_RISCV_V : uint64 := 32   // RISC-V Vector Extension
con LBF_ISA_AES_NI  : uint64 := 64   // x86 AES-NI (Hardware-Verschlüsselung)
con LBF_ISA_SHA_NI  : uint64 := 128  // x86 SHA-NI (Hardware-Hashing)

con LBF_CAP_FS_READ       : uint64 := 1
con LBF_CAP_FS_WRITE      : uint64 := 2
con LBF_CAP_NET_SOCKET    : uint64 := 4
con LBF_CAP_PROC_SPAWN    : uint64 := 8
con LBF_CAP_KI_EMBED      : uint64 := 16
con LBF_CAP_KI_GRAPH_WRITE: uint64 := 32
con LBF_CAP_SANDBOX_ACCESS: uint64 := 64
con LBF_CAP_AUDIO_MIC     : uint64 := 128
con LBF_CAP_PRIVILEGED    : uint64 := 9223372036854775808   // Bit 63

1. Genesis-Block lesen; format_version prüfen (== 0x01)
2. Compiler-UUID gegen Blacklist prüfen
3. ISA_EXTENSIONS gegen CPUID des Kernels prüfen
4. Intent + Capabilities auf Kohärenz prüfen (Semantische Firewall)
5. DEP_HASH_GRAPH auflösen → Dependency-LPIDs via Hash-Index
6. SYM_INTERFACE-Contracts verifizieren
7. IOFS-Pages für alle Blöcke anlegen, Graph-Kanten weben

1. Kernel liest Genesis-Block (IOFS-Page Typ=0x04)
   → Vertrauenskette durchlaufen
   → ISA_EXTENSIONS gegen CPUID validieren

2. Kernel erstellt neues CR3-Page-Table-Root

3. Section-Descriptor-TLV (0x08) bestimmt VA-Layout:
   .text:   0x0000000000400000 + block_index × 4096
   .rodata: folgt direkt nach .text
   .data:   folgt direkt nach .rodata
   .bss:    kein Block auf Disk — Kernel alloziert zeroed Frames

4. Für jeden Block (Block 1..N):
   lba = lip_get(block_lpid)      → O(1) LIP-Übersetzung
   pte.phys_addr = lba × 4096    → LBA direkt als physische Adresse
   pte.flags     = section.prot  → R/W/X via NX-Bit
   PTE in CR3 schreiben          → kein Kopieren, kein Parsen

5. Stack allozieren (Kernel-Default: 128 KB)

6. CPU springt zu entry_point
   → Alle Pages bereits gemappt — kein erster Page-Fault
   → Kein ELF-Interpreter, kein ld.so, kein Relokations-Loop

1. Prüfe Magic "LYX!" an Byte 0
2. format_version prüfen (== 0x01)
3. Compiler-UUID gegen ~/.lyx/compiler_blacklist.bin prüfen
4. ISA_EXTENSIONS gegen CPUID prüfen
5. Section-Descriptor-TLV (0x08) auslesen
6. Blöcke 1..N via mmap() mit korrekten Schutzrechten mappen:
   .text:   PROT_READ | PROT_EXEC
   .rodata: PROT_READ
   .data:   PROT_READ | PROT_WRITE
   .bss:    mmap(MAP_ANON) → zeroed
7. DEP_HASH_GRAPH → POSIX-Pfad-Auflösung via LD_LIBRARY_PATH
8. Springe zu entry_point

con IOFS_EDGE_LBF_CHAIN : int64 := 0xB001   // Genesis → Block 1 → Block 2 → ...
con IOFS_EDGE_LBF_DEP   : int64 := 0xD001   // Genesis → externe Bibliotheks-Genesis

# Standard: LBF für LyxOS
lyxc main.lyx --target=lyxos -o main.lbf

# Sub-Page Packing (Modus B)
lyxc main.lyx --target=lyxos --lbf-packed -o main.lbf

# Cross-Compilation
lyxc main.lyx --target=arm64 -o main_arm.lbf

# Mit expliziten ISA-Erweiterungen
lyxc main.lyx --target=lyxos --isa=avx2,amx -o main_avx.lbf

# Debug-LBF (TLV 0x06 zeigt auf lokale .lyx-Dateien)
lyxc main.lyx --target=lyxos --debug -o main.lbf

# Genesis-Block inspizieren
lbf_dump main.lbf

# Nur Vertrauenskette prüfen (Exit-Code 0/1 für CI)
lbf_dump --verify-only main.lbf

# POSIX-Ausführung
lbf_run main.lbf [args...]

# IOFS-Import
lbf_import main.lbf --into-island="tools"