Lyx Compiler – CLI Referenz

Der Lyx-Compiler (lyxc) ist ein moderner Cross-Compiler für Linux, Windows, macOS und Embedded-Systeme. Er kombiniert Compiler, Linker und statisches Analyse-Werkzeug in einem einzigen Binary.

lyxc [Optionen] <Eingabedatei(en)>

# Einfaches Beispiel
lyxc main.lyx -o main

# Mehrere Quelldateien
lyxc main.lyx utils.lyx protocol.lyx -o app

# Cross-Compilation mit vollständigem Safety-Build
lyxc main.lyx --target=arm64 --target-energy=1 --static-analysis --lint -o firmware.elf

Flags können in beliebiger Reihenfolge angegeben werden. Kurzformen (‑o) und Langformen (--output) sind gleichwertig, wo beide existieren.

Alle Schalter aus lyxc –help wurden gegen 1.1.14A einzeln nachgemessen — nicht nur am Rückgabewert, sondern am erzeugten Programm (Byte-Vergleich, file auf das Format, Lauf des Erzeugnisses).

<WRAP info> Mit 1.1.12D sind die Assembler-Schalter umgesetzt. --emit-asm, --asm-listing und --dump-asm wurden bis dahin abgewiesen (#1370) — sie arbeiten jetzt. Auch --profile und --debug-symbols wirken inzwischen. Übrig bleibt ein einziger echter Mangel: die Optimierstufen sind untereinander nicht unterscheidbar. Wer eine ältere Fassung benutzt, findet den alten Stand in der Versionsgeschichte der Seite. </WRAP>

Was sich mit 1.1.12D bis 1.1.14A geändert hat:

Was sich mit 1.0.20F geändert hat:

Zwei Schalter werden angenommen, fehlen aber in lyxc –help: --dump-ir und --meta-safe.

Es gibt keine Linker-Flags. --lib-path / -L, --link / -l und --static existieren nicht — lyxc erzeugt statische ELF-Dateien und bindet C-Bibliotheken über extern fn … link „libfoo.so“ im Quelltext ein (→ FFI). --no-libc-init wird dagegen angenommen, obwohl es in lyxc --help nicht auftaucht.

# Normaler Build (Linux)
lyxc main.lyx -o myapp

# Shared Library erstellen
lyxc mylib.lyx --shared -o libmylib.so

# Unit vorkompilieren
lyxc --compile-unit src/utils.lyx
# → erzeugt: src/utils.lyu

lyxc ist vollständig self-contained: kein externer Linker (kein ld, lld o. ä.) nötig. Der Compiler schreibt ELF64/ELF32/PE32+/Mach-O direkt in einem Schritt.

→ Ausführlicher Guide: Cross-Compilation

* StrConcat fehlt auf arm64 und riscv (#2028, nachgemessen mit lyxc 1.2.5C):

error: arm64: Builtin-ID 7 wird im Linux-Zweig nicht behandelt
error: riscv: Builtin-ID 7 wird nicht behandelt

Damit lässt sich für diese beiden Ziele praktisch kein Programm bauen, das einen berechneten Wert mit Text verbindet. Die übrigen String-Builtins sind in Ordnung — geprüft mit IntToStr, StrLen, FloatToStr und StrSub. Der Rest der IR-Ziele wurde mit #2018, #2019 und #2022 gerade nachgezogen: zuvor waren 33 bzw. 41 stdlib-Units für arm64 unbaubar.

lyxc main.lyx --target=arm64 -o firmware.elf
lyxc main.lyx --target=win64 -o app.exe
lyxc main.lyx --target=linux-riscv64 -o controller.elf
lyxc mylib.lyx --target=android --output-type=shared-lib -o libmylib.so

Alle Ziele wurden mit file auf das erzeugte Format geprüft und liefern das jeweils richtige: PE32+ für win64, Mach-O für die macOS-Ziele, ARM aarch64, RISC-V. esp32 bricht mit einer klaren Meldung ab (Zeichenkettenliterale sind fuer xtensa nicht umgesetzt) — das ist der ehrliche Umgang mit einer Lücke.

Erzwingt eine spezifische CPU-Architektur, unabhängig vom Target:

lyxc main.lyx --target=linux --arch=arm64 -o cross.elf

Verfügbare Werte: x86_64, arm64, xtensa, riscv64, arm_cm

Seit 1.0.20F wirken alle drei Werte (#1526): –format=pe liefert ein PE32+, –format=macho ein Mach-O. Vorher kam in allen Fällen ELF heraus.

--format=elf    →  ELF 64-bit LSB executable, x86-64
--format=pe     →  PE32+ executable (console) x86-64, for MS Windows

Bequemer bleibt der Weg über –target, weil dieser zugleich die Architektur und die Aufrufkonvention festlegt.

Seit 1.1.3E ist das PE-Ziel auch für fremde Bibliotheken benutzbar: extern fn … link „x.dll“ erscheint in der Import-Tabelle, Argumente gehen nach Microsoft-x64-Konvention, und eine Relokationstabelle über einer Seite (0x1000) sprengt SizeOfImage nicht mehr — vorher lehnte Windows solche Dateien als „Fehlerhaftes EXE-Format“ ab, das Programm startete gar nicht (#1672, #1671, #1674, #1676). Einzelheiten in FFI — Windows-DLLs.

Energy-Awareness-Annotationen und Compiler-Optimierungen:

Steuert das Energy-Aware-Backend. Beeinflusst Loop Unrolling, SIMD-Nutzung, Inlining-Aggressivität und Instruktions-Scheduling.

Der Schalter wirkt tatsächlich, und zwar deutlich — dasselbe Programm über alle fünf Stufen:

Stufe 1:  33 107 Byte
Stufe 2:  49 491 Byte
Stufe 3:  94 547 Byte      = Standard, entspricht dem Aufruf ohne Schalter
Stufe 4:  94 547 Byte      identisch mit Stufe 3
Stufe 5: 237 907 Byte

Damit ist –target-energy der einzige Schalter dieses Abschnitts, der etwas bewirkt — er übernimmt die Rolle, die anderswo -O hätte.

Ein Wert außerhalb von 1–5 bricht ab (Exit 2).

lyxc node.lyx --target=arm64 --target-energy=1 -o sensor.elf   # Batterie-optimiert
lyxc dsp.lyx  --target=linux --target-energy=5 -o dsp.out      # Max-Performance

–no-opt und -O0 schalten seit 1.0.20A die Vereinfachungen ab, die der Codegen beim Emittieren vornimmt — Konstantenfaltung und tote Zweige (#1371). Das Erzeugnis unterscheidet sich messbar:

Standard   d61a5580b507  4216 B
-O0        917cb3e9c87e  4222 B
--no-opt   917cb3e9c87e  4222 B
-O3        d61a5580b507  4216 B

Die Fehlerbehandlung von -O arbeitet korrekt: -O, -O9 und -Ox brechen mit lyxc: -O erwartet eine Stufe 0..3 und Exit 2 ab.

-O0 übersetzt dasselbe Programm wie die höheren Stufen. Bis lyxc 1.1.3B wies es gültige Enum-Konstanten aus importierten Units ab (der Wert von AL_NONE muss zur Uebersetzungszeit feststehen), weil die Konstantenfaltung für Enums nur im Optimierer stattfand statt in der Semantikprüfung (#1647). Damit fiel gerade die Stufe aus, die man beim Eingrenzen von Codegen-Fehlern zuerst greift.

Für stärkeren Einfluss auf die Codeerzeugung bleibt –target-energy.

Diese Flags sind für die Zertifizierung sicherheitskritischer Software gedacht. Gemessen mit 1.1.14A.

Brauchbar ist der Bericht als Strukturübersicht: er nennt Anzahl und Ort der Entscheidungspunkte je Funktion. Für einen Überdeckungsnachweis nach DO-178C Level A reicht das nicht — die Mindestzahl der Testfälle muss von Hand ermittelt werden.

@stack_limit wird bei jeder Übersetzung ausgewertet — ein früher hier dokumentiertes --stack-check gibt es nicht und ist auch nicht nötig:

$ lyxc rekursiv.lyx -o /dev/null
error: F: @stack_limit ist mit Rekursion nicht nachweisbar — die Aufruftiefe ist unbeschraenkt

Der Nachweis für @stack_limit selbst — Rahmengröße gegen die Schranke, Aufrufgraph bei Rekursion — wird seit lyxc 1.0.14K geführt, @wcet seit 1.0.14L, @flight_crit seit 1.0.14M; @redundant wirkt seit 1.0.15A auch an globalen Variablen und wird mit --verify-tmr geprüft. Ohne Nachweis bleiben @integrity, @dal und @critical — sie sind Vermerk, nicht Beweis.

lyxc flight.lyx --provenance --target=arm64 -o flight.elf

Erfasst werden Quelldatei-Hash, Compiler-Version, Flags, Ziel und die importierten Units.

Für den Nachweis gehört die Compiler-Version aus lyxc –build-info ins Prüfprotokoll — bei dieser Doku 1.0.19E.

Beide sind seit 1.0.20A umgesetzt (#1370) und ersetzen einen Teil dessen, was –emit-asm leisten sollte.

lyxc main.lyx --dump-relocs -o main

=== RELOCATION TABLE ===
  OFFSET    ART           ZIEL
  0x0000000000000033  STR          +32
  0x000000000000003A  STR          +40
  0x000000000000003F  CALL         main

–map-file legt die Karte neben dem Erzeugnis ab — bei -o main.bin also main.bin.map:

Lyx-Abbildkarte fuer h.bin

Sektionen
  NAME    ADRESSE           LAENGE
  .text   0x00000000004000b0  3920
  .data   0x0000000000401000  122

Anders als die drei Schalter im nächsten Abschnitt verändern beide das erzeugte Programm nicht.

Der Schalter wird seit 1.0.20F abgewiesen (Exit 2, #1370) — vorher wurde er angenommen und tat nichts. Die Trace-Builtins trace, trace_int und trace_str arbeiten unabhängig davon; wer die Ausgaben loswerden will, entfernt die Aufrufe aus dem Quelltext.

Für KI-Agenten, IDEs und Build-Tooling sind zwei Flags vorgesehen, die JSON (Daten & Serialisierung) auf stdout schreiben: --ast-json (Parser-AST) und --error-json (strukturierte Sema-Fehler).

Der integrierte Linter läuft als Teil des Compile-Prozesses oder eigenständig.

$ lyxc main.lyx --lint-only

main.lyx:12: Warnung [unused-var] 'temp' wird nie gelesen
main.lyx:28: Warnung [risky-cast] int64 → uint8 (mögliche Truncation)
main.lyx:41: Warnung [unbounded-loop] while ohne 'limit' in @dal(B)-Modul
main.lyx:55: Fehler   [unsafe-in-dal] unsafe-Block in @dal(A)-Modul nicht erlaubt

3 Warnungen, 1 Fehler

Stand lyxc 1.0.19E, abgeglichen mit lyxc –help und je Schalter nachgerufen — mit Vergleich des Erzeugnisses, nicht nur des Rückgabewerts. Andere als die hier genannten Schalter werden seit 1.0.15D abgewiesen (Exit 2).

Seit 1.0.20F arbeitet –config wie die beiden anderen TOR-Schalter: Exit 0, vier Zeilen, keine angehängte Hilfe (#1527). Vorher endete der Aufruf mit Exit 1 und gab 61 Zeilen aus — in einem Skript galt er damit als fehlgeschlagen.

Typische Aufrufmuster:

lyxc main.lyx -o main
./main

lyxc main.lyx --debug --no-opt -o main_dbg
./main_dbg
# Bei Absturz: vollständiger Stack-Trace mit Zeilennummern

lyxc main.lyx --lint-only -we
# -we behandelt Warnungen als Fehler; Exit != 0 laesst die Pipeline scheitern

lyxc main.lyx \
    --target=arm64 \
    --target-energy=3 \
    -o app.elf

# Auf dem Zielgerät ausführen:
scp app.elf pi@raspberrypi:~/
ssh pi@raspberrypi ./app.elf

lyxc sensor.lyx \
    --target=esp32 \
    --target-energy=1 \
    --static-analysis \
    -o sensor.elf

Seit 1.0.20F genügt ein Aufruf: –provenance verändert das Erzeugnis nicht mehr (#1523), –map-file arbeitet seit 1.0.20A. –asm-listing legt seit 1.1.14B die Auflistung mit Quellzeilen als <ausgabe>.asm ab (#1862) — ein Griff zu objdump -d ist dafür nicht mehr nötig.

lyxc flight_control.lyx \
    --target=arm64 \
    --call-graph \
    --static-analysis \
    --verify-tmr \
    --runtime-checks \
    --lint \
    --mcdc-report \
    --provenance \
    --map-file \
    -o evidence/fcc.elf  > evidence/analyse.log 2>&1

Analysen, Traceability-Protokoll, Speicherkarte (evidence/fcc.elf.map) und Auslieferungsstand entstehen damit im selben Lauf — die frühere Lücke, dass geprüfte Artefakte und ausgeliefertes Programm aus verschiedenen Übersetzungen stammten, entfällt.

# Level 1: Batterie-optimiert
lyxc dsp.lyx --target-energy=1 -o dsp_low.elf

# Level 5: Maximum-Performance
lyxc dsp.lyx --target-energy=5 -o dsp_high.elf

# Größenvergleich
ls -l dsp_low.elf dsp_high.elf

Gemessen an einem kleinen Testprogramm über alle fünf Stufen:

Stufe 1:  33 107 Byte
Stufe 2:  49 491 Byte
Stufe 3:  94 547 Byte   (Vorgabe)
Stufe 4:  94 547 Byte   identisch mit Stufe 3
Stufe 5: 237 907 Byte

Der Faktor zwischen Stufe 1 und Stufe 5 beträgt hier gut sieben. Die absoluten Zahlen hängen vom Programm ab, das Verhältnis gibt aber die Größenordnung wieder.

lyxc main.lyx --trace-passes -o main 2>&1 | grep "^\[pass\].*done"
# [pass] sema: done (1ms / 1337µs)   <- Dauer je Pass, langsamste zuerst sortierbar

lyxc main.lyx --provenance --target=arm64 -o /dev/null > audit/provenance.log

Ausgegeben wird eine Zuordnung von IR-Instruktionen über AST-Knoten zur Quellzeile:

=== PROVENANCE ===
IR[0] irLoadLocal  ->  AST[6] IF  ->  src:main.lyx:1
IR[1] irConstInt   ->  AST[6] IF  ->  src:main.lyx:1
IR[2] irCmpLe      ->  AST[6] IF  ->  src:main.lyx:1

<WRAP alert> Drei Dinge weichen von früheren Fassungen dieser Seite ab:

• Es entsteht keine .prov-Datei. Die Ausgabe geht ausschließlich nach stdout und muss umgeleitet werden.
• Erfasst wird nicht Quelldatei-Hash, Compiler-Version, Flags und Ziel, sondern allein die IR→AST→Quelle-Zuordnung. Version und Ziel holt man sich aus --build-info.
• Die Zeilennummern stimmen weitgehend nicht (#1523): bei einem 22-zeiligen Programm mit drei Funktionen verwiesen 77 von 85 Einträgen auf Zeile 1 — die Importzeile. Für einen Traceability-Nachweis nach DO-178C 6.4.4.2b reicht das nicht.

Seit 1.0.20F ist das dabei erzeugte Programm regulär lauffähig; -o /dev/null steht hier nur, weil allein das Protokoll gebraucht wird. </WRAP>

lyxc kennt kein --define / -D-Flag für Präprozessor-Symbole, weil Lyx keinen Präprozessor hat. Die Alternativen:

→ Ausführlich: Bedingungen – Kein Präprozessor in Lyx (Abschnitt 7)

Weiterführende Seiten:

• Compiler selbst kompilieren – Bootstrap, Selbstkompilierung, Singularitätsprüfung
• Attribute & Pragmas – vollständige @-Referenz
• Aerospace & Safety – @flight_crit, DO-178C
• Aerospace Tutorial – vollständiger Zertifizierungs-Workflow
• Energy-Aware Programmiermodell – --target-energy im Detail
• Memory Management – @stack_limit
• DO-178C Compliance – MC/DC, Call-Graph, Provenance

Letzte Aktualisierung: 2026-09-05 (#1647, nachgemessen mit lyxc 1.2.2B) — -O-Kasten präzisiert: -O0/--no-opt erzeugen inzwischen ein anderes Erzeugnis, -O1…-O3 bleiben untereinander gleich.

Vorherige letzte Aktualisierung: 2026-08-31 — die drei Assembler-Schalter gegen 1.1.15B nachgemessen (#1862 geschlossen): –dump-asm schreibt nach stdout, –emit-asm die Datei ohne Quellzeilen, –asm-listing die Datei mit Quellzeilen. Zuvor am 2026-08-30 alle Schalter gegen 1.1.14A gemessen. Neu: Projektdatei *.lpf (eigene Seite). –emit-asm/–asm-listing/–dump-asm sind umgesetzt (#1370 geschlossen), ebenso –profile und –debug-symbols; –dump-relocs und –map-file arbeiten. Offen bleibt allein, dass die Optimierstufen untereinander byte-gleich sind (#1371).

Vorherige Aktualisierung: 2026-08-16 — alle Schalter gegen 1.0.20F neu gemessen (Byte-Vergleich, file, Lauf des Erzeugnisses). Von dreizehn zuvor defekten Schaltern sind elf in Ordnung: –dump-ir/–ir-source-map/–provenance liefern wieder ein lauffähiges Programm (#1523), –mcdc-report zählt Bedingungen richtig (#1524), –format und –arch wirken (#1526), –config endet mit Exit 0 (#1527). Offen: –mcdc instrumentiert nicht, –debug-symbols ohne Wirkung, -O1..-O3 untereinander gleich (#1371).