Unter der Haube.
Was wirklich passiert,
wenn dein Code läuft.

01 Übersetzung

Der Prozessor kennt kein if

Er kennt Zahlen. Zwischen deiner Textdatei und der CPU stehen vier Werkzeuge, die nacheinander übersetzen — jedes mit genau einer Aufgabe.

1 — was du schreibst · Cint quadrat(int n) { return n * n; }

2 — was der Compiler daraus macht · Assemblyquadrat:
  endbr64
  imul   %edi, %edi
  mov    %edi, %eax
  ret

3 — was die CPU liest · Maschinencodef3 0f 1e fa  0f af ff  89 f8  c3

[i]Nicht ausgedacht: erzeugt mit gcc -O2 -c quadrat.c und objdump -d auf x86-64. endbr64 ist eine Sicherheitsmarke moderner Intel-CPUs. Ohne Optimierung baut der Compiler zusätzlich einen Stack Frame auf (Kapitel 05); auf einem ARM-Prozessor stehen dort völlig andere Bytes.

02 Ausführung

Drei Wege, dasselbe Ziel

„Kompiliert oder interpretiert“ ist eine Vereinfachung. Der eigentliche Unterschied ist, wann übersetzt wird.

[i]Vereinfacht: Diese Wege gehören nicht zur Sprache, sondern zur Implementierung. Es gibt C-Interpreter und Java-Compiler, die direkt Maschinencode erzeugen (GraalVM Native Image). „Python ist interpretiert“ beschreibt genau genommen CPython, nicht Python.

03 Variable

Ein Name für eine Adresse

Der Speicher ist ein durchnummeriertes Regal aus Bytes. Eine Variable ist ein Name für ein Fach — und der Typ sagt, wie viele Fächer und wie man sie liest.

Cint alter = 30;

printf("%p",  (void*)&alter);  // 0x7ffd…2ca0 — wo es liegt
printf("%zu", sizeof alter);     // 4          — wie viele Fächer

[i]Vereinfacht: Bytereihenfolge „little-endian“ (üblich auf x86 und ARM), int vier Byte groß — beides ist plattformabhängig, nicht garantiert. Der Float-Wert ist eine sogenannte denormale Zahl dicht an null — absurd weit von 30 entfernt, obwohl kein Bit anders steht. Sauber liest man Bits in C mit memcpy oder einer union um, nicht mit einem Zeiger-Cast.

04 Speicherbild

Vier Bereiche, zwei Richtungen

Jedes laufende Programm bekommt einen eigenen Adressraum. Er zerfällt in Bereiche mit sehr unterschiedlichen Regeln — und zwei davon wachsen aufeinander zu.

[i]Vereinfacht: Das ist virtueller Speicher — jeder Prozess sieht dieses Bild für sich allein, das Betriebssystem verteilt den echten Arbeitsspeicher dahinter. Die genaue Anordnung ist plattformabhängig, und ASLR verschiebt die Bereiche bei jedem Start absichtlich, damit Angreifer keine festen Adressen vorfinden.

05 Stack Frame

Ein Rahmen pro Aufruf

Jeder Funktionsaufruf legt einen Rahmen auf den Stapel: Parameter, lokale Variablen und die Adresse, an der es danach weitergeht. Das return räumt ihn wieder ab.

[i]Vereinfacht: Auf x86-64 werden die ersten Argumente in Registern übergeben und landen gar nicht im Rahmen, und ein Compiler mit Optimierung macht aus dieser Rekursion womöglich eine Schleife ganz ohne neue Rahmen. Das Bild hier ist das Lehrbuchmodell — und genau das, was dir ein Debugger als Aufrufliste anzeigt.

06 Lebensdauer

Der Rahmen geht, die Adresse bleibt

Eine lokale Variable lebt genau so lange wie der Rahmen, in dem sie liegt. Danach ist ihre Adresse nur noch eine Zahl, die irgendwohin zeigt.

C — so nichtint* kaputt(void) {
    int x = 42;
    return &x;      // die Adresse überlebt — x nicht
}

[i]Das ist undefiniertes Verhalten: Der C-Standard legt nicht fest, was passiert. Ein sofortiger Absturz wäre der freundliche Fall — der unfreundliche ist ein Programm, das jahrelang fast richtig rechnet.

07 Stack gegen Heap

Zwei Speicher, zwei Verträge

Beide geben dir Platz. Der Unterschied ist, wer aufräumt — und was das kostet.

Cint a[3];                       // Stack — weg beim return
int *b = malloc(3 * sizeof *b);  // Heap  — bleibt bis free(b)

[i]Vereinfacht: 8 MB ist der übliche Linux-Standardwert (ulimit -s zeigt ihn an); zusätzliche Threads bekommen oft weniger. In Sprachen mit Garbage Collector liegen fast alle Objekte auf dem Heap — die Unterscheidung verschwindet dadurch nicht, sie wird nur unsichtbar.

08 Kopie oder nicht

b = a kopiert nicht immer

Der häufigste Anfängerfehler ist kein Tippfehler. Er kommt daher, dass zwei Namen auf dasselbe Objekt zeigen — und man nur einen davon anfasst.

Pythona = [1, 2, 3]
b = a          # nur ein zweiter Name
b.append(4)
print(a)       # [1, 2, 3, 4] — a hat sich mitverändert

c = a[:]       # jetzt eine echte Kopie
c.append(5)
print(a)       # [1, 2, 3, 4] — unverändert

[i]Vereinfacht: a[:] erzeugt eine flache Kopie. Enthält die Liste selbst wieder Listen, teilen sich beide Kopien deren innere Objekte weiterhin — dafür gibt es copy.deepcopy. Kleine Zahlen und kurze Zeichenketten hält CPython außerdem als gemeinsame Objekte vor, was beim Ausprobieren mit is verwirrt.

09 Fehlerbilder

Drei Abstürze, die jetzt Sinn ergeben

Die bekanntesten Laufzeitfehler sind keine Magie. Sie sind die direkte Folge der letzten fünf Kapitel — und man sieht ihnen an, wo sie herkommen.

[i]In Sprachen mit Garbage Collector gibt es keine hängenden Zeiger — Lecks aber sehr wohl: Eine vergessene Referenz in einer langlebigen Liste hält ihr Objekt am Leben, obwohl niemand es mehr braucht. Der Aufräumer kann nicht wissen, dass du es nicht mehr willst.

10 Fazit

Warum sich das rechnet