C ist keine Low-Level-Sprache (2018)

• Ein Artikel, der entgegen der verbreiteten Annahme argumentiert, dass C keine Low-Level-Sprache ist
• Der Autor David Chisnall schlägt vor, dass die Schwachstellen Meltdown und Spectre auf die Fähigkeit von Prozessoren zurückgehen, Befehle unter Umgehung von Zugriffsprüfungen auszuführen, und dass diese Fähigkeit hinzugefügt wurde, damit C-Programmierer glauben, sie würden in einer Low-Level-Sprache programmieren.
• Chisnall argumentiert, dass „nah am Metall“ zu sein bedeutet, dass eine Sprache eine abstrakte Maschine bereitstellen muss, die sich leicht auf die von der Zielplattform offengelegten Abstraktionen abbilden lässt, und behauptet, dass dies bei C nicht der Fall ist.
• Der Autor vermutet, dass die eigentliche Ursache der Schwachstellen Spectre und Meltdown darin liegt, dass Prozessorarchitekten versucht haben, schnelle Prozessoren zu bauen, die abstrakte Maschinen wie den PDP-11 offenlegen, wodurch C-Programmierer weiterhin glauben konnten, ihre Sprache sei nahe an der zugrunde liegenden Hardware.
• Chisnall behauptet, dass es Tausende Personenjahre und komplexe Compiler-Transformationen braucht, um C-Code schnell auszuführen und Compiler zu bauen, die dafür intelligent genug sind.
• Der Autor schlägt vor, dass die Kerneigenschaft einer Low-Level-Sprache darin besteht, dass Programmierer leicht verstehen können, wie die abstrakte Maschine der Sprache auf die zugrunde liegende physische Maschine abgebildet wird, und argumentiert, dass dies bei C nicht zutrifft.
• Chisnall kommt zu dem Schluss, dass es vielleicht an der Zeit ist, nicht länger zu versuchen, C-Code schnell zu machen, und stattdessen darüber nachzudenken, wie ein Programmiermodell auf schnellen Prozessoren aussehen sollte. Er vermutet, dass ein rein auf Geschwindigkeit ausgelegter Prozessor wahrscheinlich sehr viele Threads unterstützen, breite Vektoreinheiten besitzen und ein deutlich einfacheres Speichermodell haben würde.

[GN⁺]

Hacker News-Diskussion

• Der Artikel behauptet, dass C keine Low-Level-Sprache sei, weil es manuelle Speicherverwaltung und explizite Aufrufe von Allokatoren erfordert.
• Einige Kommentierende argumentieren, dass C für diejenigen, die es verstehen und fachkundig einsetzen, tatsächlich eine Low-Level-Sprache ist.
• Der Behauptung des Autors, dass CPU-Befehlssätze mehr von der Implementierung der CPU offenlegen sollten, wird unter Verweis auf gescheiterte Versuche in der Vergangenheit widersprochen.
• Das Konzept von Low-Level bis High-Level erscheint als Spektrum, und C befindet sich unter den Sprachen, die maschinennahe Primitive wie Speicher- und Thread-Verwaltung offenlegen, eher auf der unteren Seite.
• Die Behauptung des Artikels, dass paralleles Programmieren nicht schwierig sei, halten einige Kommentierende für irreführend.
• Die Prämisse des Artikels, dass Computer der Architektur des PDP-11 nicht ähneln, wirkt zutreffender denn je, aber die Schlussfolgerung, sich Nicht-C-Prozessoren vorzustellen, scheint nicht besonders überzeugend.
• Einige Kommentierende meinen, die Aussage des Artikels, dass Computer kein schneller PDP-11 seien, stimme zwar, aber die Verbindung zu C sei falsch.
• Die Behauptung des Artikels, dass C keine Low-Level-Sprache sei, wirkt angesichts von Eigenschaften wie struct-Padding und dem undefinierten Verhalten bei Signed Overflow konstruktiv.
• Das Argument, dass CPU-Designer wegen der Dominanz von C zwangsläufig etwas bauen mussten, das C auf natürliche Weise ausführen kann, erscheint schlüssig, aber wie das mit der ersten Behauptung und dem Titel des Artikels zusammenhängt, bleibt unklar.
• Wenn die ausgefeilte Technik moderner CPUs dazu führt, dass C nicht mehr als „Low-Level“-Sprache gilt, dann gilt das ebenso für Assemblersprache.
• Der Artikel erinnert einige Kommentierende an VLIW, bei dem ein einzelner VLIW-Befehl mehrere unabhängige Befehle enthalten kann, die parallel ausgeführt werden können.