Lyx – Attribute & Pragmas (@-Referenz)

Attribute (auch Pragmas genannt) sind Compiler-Anweisungen, die mit @ beginnen und vor einer Deklaration stehen. Sie steuern Optimierungen, Sicherheits-Verifikation, Speicherlayout und FFI-Verhalten. Attribute verändern nie die Semantik des Programms für korrekte Eingaben — sie sind Zusatzinformationen für den Compiler, nicht für den Laufzeit-Interpreter.

→ Compiler-Flags (CLI) · DO-178C Compliance · Energy-Aware Modell · FFI – C-Interop

Alle Attribute auf einen Blick:

Jedes Attribut einzeln übersetzt, jeweils gegen dasselbe Programm ohne Attribut verglichen (Rückgabewert, Meldungen, Größe des Erzeugnisses).

Externe Funktionen werden ohne Attribut deklariert — mit dem Schlüsselwort extern (siehe FFI).

Attribute für sicherheitskritischen und zertifizierungspflichtigen Code:

Legt das Design Assurance Level nach DO-178C fest. Beeinflusst, welche Lint-Prüfungen aktiv sind und ob bestimmte Sprachfeatures verboten werden.

@dal(A)
unit flight_control;

@dal(B)
fn ProcessSensorData(raw: int64): int64 { ... }

Aktiviert den strengsten Kompilierungsmodus für sicherheitskritische Funktionen:

@flight_crit
@dal(A)
@stack_limit(512)
fn ComputeFlightPath(state: int64): FlightCommands { ... }

Wirkung zur Laufzeit: Der Prolog der Funktion schaltet die SSE-Ausnahmen für invalid (NaN) und divide-by-zero frei und sichert MXCSR, der Epilog stellt den alten Wert wieder her. Eine entstehende NaN oder Inf löst damit SIGFPE aus statt still weiterzurechnen; der mitgegebene Handler meldet panic: FPU-Ausnahme (NaN/Inf oder Division durch 0) unter @flight_crit in `NAME` und endet mit 134. Die Reichweite ist dynamisch: MXCSR ist Thread-Zustand, der Trap gilt also auch für alles, was die Funktion ruft, bis sie zurückkehrt. Überlauf, Unterlauf und Ungenauigkeit bleiben maskiert.

Impliziert automatisch:

• @energy(1) — kein aggressives Unrolling, keine SIMD-Spekulation
• keine FPU-Optimierungen für diese Funktion (ein globales Flag dafür gibt es nicht)
• Verbot von new/alloc im Rumpf
• Verbot von Rekursion ohne @stack_limit
• Exhaustive match über alle Enum-Werte (kein default in DAL-A)

Das Speicherverbot ist seit lyxc 1.0.21B durchgesetzt (#1529) und meldet, gemessen mit 1.1.3I:

sema error: Speicheranforderung unter @flight_crit nicht erlaubt 'alloc'
sema error: new ist unter @flight_crit nicht erlaubt — der Speicher muss ausserhalb angelegt und hereingereicht werden
sema error: lokales Feld unter @flight_crit nicht erlaubt (es entsteht per mmap, nicht auf dem Stapel)

Kompatibel mit @energy(2) wenn explizit annotiert (zulässig für DAL-B):

@flight_crit
@energy(2)   // energy-Barriere: überschreibt das implizite @energy(1)
@dal(B)
fn FilterAltitude(raw: f64): f64 { ... }

Aktiviert Laufzeit-Integritätsprüfung. Zwei Modi:

// Modus 1: Memory Scrubbing (periodischer CRC32-Sweep des Code-Segments)
@integrity(mode: scrubbed, interval: 100)
unit nav.core;

// Modus 2: Software Lockstep (duplizierte ALU-Operationen, Vergleich vor Return)
@integrity(mode: software_lockstep)
@dal(A)
fn ComputeHeading(imu: int64): f64 { ... }

→ Details: Memory Scrubbing · Software Lockstep

Speichert eine Variable dreifach im RAM (Sektionen .tmr_a, .tmr_b, .tmr_c). Jeder Lesezugriff führt einen Mehrheitsentscheid durch; ein korrumpiertes Exemplar wird automatisch repariert.

@redundant
var flight_mode: int64 := 0;

@redundant
var altitude_m: f64 := 0.0;

• Nur für globale und Unit-Level-Variablen; Stack-Variablen werden vom Compiler abgelehnt
• Speicherbedarf: 3× Variablengröße plus Alignment
• Die Adresse-von-Form @x liefert die Adresse einer Kopie und umgeht damit den Voter — ein Schreibzugriff darüber geht beim nächsten Mehrheitsentscheid verloren. Der Compiler meldet das: unter --verify-tmr als Fehler, sonst als Warnung
• --verify-tmr druckt die Bilanz (Variablen, gevotete Lesezugriffe, dreifache Schreibzugriffe, Umgehungen) und endet mit Exit 1, sobald ein Zugriff am Voter vorbeigeht

→ Details: TMR

Setzt ein hartes Limit für den Stack-Verbrauch einer Funktion in Bytes. Wird bei jeder Übersetzung geprüft — ein Flag dafür gibt es nicht und ist nicht nötig. Geprüft werden zwei Dinge: die Rahmengröße der Funktion selbst gegen die Schranke, und dass die Funktion nicht rekursiv ist (auch nicht indirekt über den Aufrufgraphen) — ohne nachweisbare Aufruftiefe wäre der Verbrauch unbeschränkt. Beides sind harte Fehler. Nicht erfasst: der Verbrauch der aufgerufenen Funktionen entlang der Aufrufkette und dynamisch angeforderter Speicher. Zu beachten: ein [N]int64 liegt nicht im Rahmen — Arrays bekommen einen Heap-Block, der Rahmen wächst nur um 8 Byte je Variable.

@stack_limit(2048)
fn ParsePacket(buf: pchar, len: int64): bool { ... }

@stack_limit(128)
@flight_crit
fn SysTick_Handler(): void { ... }   // ISR: sehr wenig Stack erlaubt

• Bei Überschreitung: Compiler-Fehler (kein Laufzeitfehler)
• Rekursion ohne nachweisbare Schranke → automatischer Fehler

Gibt die maximal erlaubte Worst-Case Execution Time in Iterationen an — nicht in CPU-Zyklen. Eine Zyklenzahl bräuchte ein Mikroarchitekturmodell; Iterationen sind das, was sich am Syntaxbaum abzählen lässt.

@wcet(200)
@dal(A)
fn ReadIMU(buf: int64): void { ... }

@wcet(500)
fn FilterAltitude(raw: f64): f64 { ... }

• Der Compiler zählt die Iterationen kumulativ über Loop-Bounds und Aufrufgraph: eine Schleife mit Schranke B, in deren Rumpf I Iterationen stecken, trägt B * (1 + I) bei — zwei geschachtelte Zehnerschleifen ergeben 110
• Abzählbar sind for … to/downto und for i in a..b mit literalen Grenzen, for i in range(A, B), while © limit(N) und while (i < C) mit literalem Startwert, konstanter Grenze und genau einer Fortschaltung i := i + K, K > 0
• Alles andere ist in einer @wcet-Funktion ein Fehler, kein stiller Durchlass: berechnete Schleifengrenzen, repeat/until, das C-artige for, Rekursion (auch indirekt) und der Aufruf einer Funktion ohne eigene Schranke — importierte Funktionen eingeschlossen, PrintLn also auch
• Software-Lockstep verdoppelt die effektive WCET (~2×)
• Ein --wcet-Flag gibt es nicht — der Nachweis läuft bei jeder Übersetzung. Für den Aufrufgraphen --call-graph verwenden

Steuert das Energy-Aware-Backend für diese Funktion. Es überschreibt das globale –target-energy-Level und erzeugt eine Energy-Barriere — inlinierte Aufrufer übernehmen das Level dieser Funktion nicht.

Die Vorrangregel lautet seit lyxc 1.0.15C:

1. @energy(N) an der Funktion
2. @energy(N); als Direktive im Quelltext
3. –target-energy=N auf der Kommandozeile
4. Vorgabe 3

Der Quelltext schlägt also das Flag. Zu beachten: Funktionen ohne Attribut — auch die aus importierten Units — folgen weiterhin dem Flag; ein Programm ist deshalb mit und ohne –target-energy nur dann byteidentisch, wenn jede beteiligte Funktion annotiert ist.

@energy(1)
fn IdleSensor(): void { ... }     // Batterie-optimiert

@energy(5)
fn MatMulKernel(a: int64, b: int64, out: int64): void { ... }  // Max-Performance

→ Details und Level-Tabelle: Energy-Aware Modell

Unterdrückt Alignment-Padding in einer Struct-Definition. Felder folgen ohne Lücken aufeinander. Notwendig für Hardware-Register-Maps, Netzwerk-Paket-Header, binäre Protokolle.

Es gibt zwei gleichwertige Schreibweisen — das Attribut vor der Deklaration oder das Schlüsselwort packed vor struct:

@packed
type CANFrame = struct {
    id:   int32;   // 4 Bytes (11-Bit-ID + Flags)
    dlc:  int8;    // 1 Byte  (Data Length Code)
    data: int64;   // 8 Bytes (Nutzdaten)
}

type IpFragment = packed struct {
    ident:    int16;
    frag_off: int16;
    ttl:      int8;
}

Felder stehen ohne var und die Struktur braucht die Form type Name = struct. Ein alleinstehendes class Name { … } wie in C++ oder Java weist der Compiler mit unexpected top-level token ab.

Die Wirkung lässt sich mit sizeof nachmessen:

type Locker = struct        { a: int16; b: int8; c: int16; }
type Dicht  = packed struct { a: int16; b: int8; c: int16; }

fn main(): int64 {
    PrintLn("struct        = ", IntToStr(sizeof(Locker)));
    PrintLn("packed struct = ", IntToStr(sizeof(Dicht)));
    return 0;
}

struct        = 6
packed struct = 5

Fünf Nutzbytes gegen sechs: die reguläre Ausrichtung legt jedes Feld auf ein Vielfaches seiner eigenen Breite (int16 auf 2, int8 auf 1) — a auf 0, b auf 2, ein Füllbyte, c auf 4. Das entspricht dem Speicherbild eines C-Structs. Bis 1.0.21A lag jedes Feld auf einer 8-Byte-Grenze (#1516), derselbe Struct maß dort 18 Byte; ältere Fassungen dieser Seite zeigen diese Zahl. packed bleibt für Protokollköpfe richtig, wo auch das eine Füllbyte stört — nachgemessen mit 1.1.14A.

• Unaligned-Zugriffe können auf manchen Architekturen (ARM Cortex-M0) Faults auslösen
• Auf x86_64 immer sicher, auf ARM64 mit LDUR/STUR

Markiert ein Struct-Feld als Big-Endian (Network Byte Order). Lese- und Schreibzugriffe auf das Feld erzeugen automatisch Byte-Swap-Instruktionen (bswap auf x86_64, rev auf ARM64).

type IpHeader = packed struct {
    @big_endian ethertype: int16;   // z. B. 0x0800 für IPv4
    @big_endian total_len: int16;
    @big_endian ident:     int16;
    @big_endian frag_off:  int16;
                ttl:       int8;
                protocol:  int8;
    @big_endian checksum:  int16;
};

Das Attribut steht direkt vor dem Feldnamen — ohne var und ohne Offset-Angabe. Für ein festes Speicherbild sorgt packed struct (→ Datentypen).

Seit lyxc 1.0.15G schreibt eine Feldzuweisung genau so viele Bytes, wie das Feld breit ist (mov [rax+off], sil / si / esi bei 1, 2 und 4 Byte) — Nachbarfelder bleiben unberührt, in gepackten wie in ungepackten Strukturen. Die Reihenfolge der Zuweisungen spielt damit keine Rolle mehr.

• Nur sinnvoll für Felder ≥ 2 Bytes (int8 ist byteorder-neutral)
• Der Swap greift bei jedem Zugriff, in beide Richtungen. Schreiben und anschließendes Lesen desselben Feldes liefert deshalb wieder den Ausgangswert — sichtbar wird die Wirkung erst am Rohspeicher: Steht dort die 1, liefert das @big_endian-Feld 16777216 (0x01000000).

unit main;
@resource("splash", "assets/splash.lyxi");

import std.res;

fn main(): int64 {
    var bild: pchar := ResFind("splash");
    var n:    int64 := ResLen("splash");
    return 0;
}

var s: pchar := @embed("assets/hilfe.txt");
var n: int64 := @embed_len("assets/hilfe.txt");

@capabilities([system.exit, system.memory.heap, system.time])
import std.io;

extern fn time(t: int64): int64 link "libc.so.6";

fn main(): int64 {
    PrintLn(IntToStr(time(0)));
    return 0;
}

fn main(): int64 {
    @align(64) var puffer: array<int64> := [1, 2];
    return puffer[0];
}

@volatile var uart_data_reg: int64 := 0x40011004;   // UART-Datenregister-Adresse
@volatile var isr_flag:      int64 := 0;             // Gesetzt von ISR, gelesen von Main

fn WaitForData(): void {
    while (isr_flag == 0) limit(1000000) { }   // Ohne @volatile würde der Compiler dieses Loop wegoptimieren
    isr_flag := 0;
}