====== Lyx – Low-Level: Pointer & Inlining ======

Obwohl Lyx durch Funktionen wie [[Lyx – Memory Management|Null-Safety]] und [[DO-178C Compliance|Range-Checks]] schützt, benötigt die Systemprogrammierung (Treiber, Kernel, Echtzeit-Regler) direkten Zugriff auf Speicheradressen und präzise Kontrolle über den generierten Maschinencode.

===== 1. Pointer (Zeiger) =====

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

==== Deklaration und Nutzung ====
<code lyx>
var x: int64 := 42;
var p: ^int64 := ^x; // Pointer auf x (Address-of)

PrintInt(p^); // Dereferenzierung (Zugriff auf den Wert an Adresse p)
</code>

==== Memory Mapped I/O (MMIO) ====
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.

<code lyx>
@volatile
var GPIO_BASE: ^uint32 := 0x3FF44000 as ^uint32;

fn toggle_led() {
    GPIO_BASE^ := GPIO_BASE^ ^ 0x1; // Bit-Flip am Hardware-Register
}
</code>



===== 2. Funktions-Inlining (@inline) =====

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).

==== Das @inline Attribut ====
<code lyx>
@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'
}
</code>

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

==== Kontrolle via CLI ====
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 [[lyx_-_programmiersprache:das-energy-aware-programmiermodell|Energy-Level]], ob Inlining sinnvoll ist.



===== 3. Unsafe-Blöcke =====

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

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

<box gh>
> **Sicherheits-Warnung:**
> In Modulen mit **@dal(A)** oder **@flight_crit** erzeugt die Verwendung von ''unsafe'' oder rohen Pointern eine Compiler-Warnung oder einen Fehler, sofern keine explizite Ausnahme definiert wurde.
</box>
===== 4. Zusammenfassung: Wann was nutzen? =====

^ Feature ^ Einsatzgebiet ^ Risiko ^
| **Pointer (^T)** | Treiber, Hardware-Register, Low-Level Buffer | Null-Pointer, Memory Corruption |
| **@volatile** | Hardware-Register, Shared Memory (Multicore) | Keine (verhindert Fehloptimierung) |
| **@inline** | Mathematische Hilfsfunktionen, Getter/Setter | Code-Größe steigt |
| **unsafe** | Pointer-Arithmetik, FFI zu C-Bibliotheken | Umgeht alle Sicherheitsgarantien |