Compiler & Interpreter

Wie aus Text ein laufendes Programm wird — lexen, parsen, durchlaufen. Jeder baut darauf; wenige schauen hinein.

Als Nächstes empfohlen → Sprachfähigkeit · GEIST

Der Beitrag

Im Jahr 1957 veröffentlichte ein IBM-Team unter Leitung von John Backus FORTRAN und beendete damit einen Streit, den die meisten Programmierer für unentscheidbar hielten. Bis dahin schrieb man, um einen Rechner schnell zu machen, seine rohen Befehle von Hand; der Gedanke, eine Maschine könne menschenfreundliche Formeln in Code übersetzen, der so knapp ausfällt wie der eines Fachmanns, galt vielen als Hirngespinst. Backus' Team bewies über drei Jahre das Gegenteil, und das Ergebnis lief nah genug an handgeschriebenem Assembler, dass der Einwand schlicht in sich zusammenfiel. Das Programmieren war danach ein anderes: Man konnte schreiben, was man meinte — eine mathematische Formel — und einem Programm, dem Compiler, die Seite der Maschine überlassen. Fast siebzig Jahre später tut jeder Compiler unter aller Raffinesse noch immer diese eine Aufgabe.

Ein Compiler versteht sich am besten als eine Folge von Übersetzungen, deren jede das Programm eine Stufe näher an die Maschine hinabsenkt. Er beginnt damit, den rohen Text zu lesen und die Zeichen zu Wörtern zu gruppieren; dann arbeitet er die grammatische Struktur heraus, ähnlich wie man einen Satz zergliedert, und verwandelt den flachen Strom der Wörter in einen verzweigten Baum, der festhält, was worin verschachtelt ist. Aus diesem Baum baut er eine innere Darstellung, bewusst aller menschlichen Bequemlichkeiten entkleidet — eine schlichte, regelmäßige Form, die sich leicht umordnen lässt —, und hier geschieht die eigentliche Arbeit der Optimierung: Konstanten werden im Voraus berechnet, unerreichbarer Code wird weggeworfen, wiederholte Rechnungen werden geteilt, Schleifen umgeformt, alles, um das spätere Ergebnis schneller zu machen, ohne zu ändern, was es tut. Erst ganz am Ende gibt er die tatsächlichen Befehle für einen bestimmten Prozessor aus. Die alte Trennlinie zwischen kompilierten und interpretierten Sprachen hat sich weitgehend aufgelöst: Die meisten sogenannten interpretierten Sprachen übersetzen im Stillen zuerst in einen kompakten Zwischencode, und die schnellsten Systeme beobachten ein Programm im Lauf, bemerken, welche Strecken heiß sind, und kompilieren gerade diese zur Laufzeit in nativen Code. Durch all das zieht sich das Typsystem, die tiefste Kraftquelle des Compilers — der Bestand an Regeln, der entscheidet, welche Fehler er abfangen kann, ehe das Programm überhaupt läuft. Ein strenges Typsystem weigert sich, ein Programm zu bauen, das eine Zahl zu einem Stück Text zu addieren versucht; ein nachsichtiges lässt diesen Fehler warten, bis der Code läuft und ein Benutzer ihm beim Scheitern zusieht. Diese eine Entscheidung, weit mehr als die reine Geschwindigkeit, verleiht der einen Sprache ihren vorsichtigen und der anderen ihren freizügigen Charakter.

Warum jetztDer Compiler-Stack ist im Stillen zum Substrat des KI-Booms geworden. Die offene Compiler-Infrastruktur LLVM, um das Jahr 2000 als Doktorarbeit begonnen, liegt heute unter den Werkzeugketten einer Sprache nach der anderen, während eine spezialisierte Schicht von Compilern das hochsprachige Python von Modellen des maschinellen Lernens in die dichten GPU-Befehle übersetzt, die ein Trainingslauf tatsächlich ausführt — und wie gut sie das tun, ist ein großer Teil des Grundes, warum die Modelle des einen Labors schneller trainieren als die des anderen. WebAssembly lässt Code, der in nahezu jeder Sprache geschrieben ist, mit annähernd nativer Geschwindigkeit im Browser laufen. Und am oberen Ende des Stapels ist eine neue Wendung erschienen: KI-Assistenten schreiben nun einen großen Teil des Quelltexts, den der klassische Compiler dann in Maschinenbefehle übersetzt — was die Frage wahrhaft offen lässt, ob die menschenlesbare Sprache in der Mitte überhaupt immer gebraucht wird.