Lyx – Low-Level: Pointer & Inlining

Obwohl Lyx durch Funktionen wie Null-Safety und Range-Checks schützt, benötigt die Systemprogrammierung (Treiber, Kernel, Echtzeit-Regler) direkten Zugriff auf Speicheradressen und präzise Kontrolle über den generierten Maschinencode.

Pointer speichern die physikalische oder virtuelle Speicheradresse eines Objekts. In Lyx wird zwischen sicheren Referenzen und rohen Pointern unterschieden.

var x: int64 := 42;
var p: ^int64 := ^x; // Pointer auf x (Address-of)
 
PrintInt(p^); // Dereferenzierung (Zugriff auf den Wert an Adresse p)

Für die Kommunikation mit Hardware (z.B. auf dem ESP32 oder RISC-V) wird oft das Attribut @volatile verwendet, um zu verhindern, dass der Compiler Zugriffe wegoptimiert.

@volatile
var GPIO_BASE: ^uint32 := 0x3FF44000 as ^uint32;
 
fn toggle_led() {
    GPIO_BASE^ := GPIO_BASE^ ^ 0x1; // Bit-Flip am Hardware-Register
}

Inlining ist eine Optimierung, bei der der Compiler den Funktionsaufruf durch den tatsächlichen Code der Funktion ersetzt. Dies eliminiert den Overhead des Funktionsaufrufs (Register-Saving, Stack-Frame-Setup).

@inline
fn fast_add(a: int, b: int): int {
    return a + b;
}
 
fn main() {
    var sum := fast_add(5, 10); // Der Maschinencode enthält hier direkt ein 'add'
}

• Vorteil: Deutlich schneller bei kleinen, oft aufgerufenen Funktionen.
• Nachteil: Vergrößert die Binärdatei (Code Bloat), was den Instruction-Cache belasten kann.

Das Inlining kann global über den Compiler gesteuert werden, wird aber durch das Attribut @inline pro Funktion erzwungen. Das Backend entscheidet bei Standardfunktionen selbstständig basierend auf dem Energy-Level, ob Inlining sinnvoll ist.

Für Operationen, die die Typsicherheit umgehen (z.B. Pointer-Arithmetik oder Casts zwischen inkompatiblen Typen), bietet Lyx den unsafe-Bereich.

unsafe {
    var raw_ptr: ^uint8 := get_buffer_address();
    var offset_ptr := raw_ptr + 16; // Pointer-Arithmetik ist nur in unsafe erlaubt
}