Grundsatzdiskussion um Compiler

Kamikaze

Kamikaze

Warrior of Sunlight
Teammitglied
In den tiefen des Internets bin ich auf diese Mail in einer OpenBSD Mailingliste gestoßen. Die zentrale Forderung ist ein Compiler mit Long-Term-Support der den vollen Satz C/C++ Features unterstützen soll und nur mit minimalem Performancefirlefanz daherkommt:
http://marc.info/?l=openbsd-misc&m=137530560232232&w=2

Die Schlussfolgerungen sind für mich schlüssig und eigentlich universell gültig. Auch ich habe in meinem Leben schon diverse Compiler-Fehler entdeckt (im Embedded Bereich, sowohl bei Closed-Source als auch bei Open Source Compilern). Ich behelfe mich damit einfach so viele Compiler wie möglich zu verwenden und zu testen. So habe ich im Notfall immer irgend einem mit dem es gerade funktioniert. Aus dieser Erfahrung kann ich den Wunsch nach einem zuverlässigen Compiler voll nachvollziehen.

Damit meine Stellungnahme da nicht so in der Luft hängt, wie seht ihr das?
 
Auf freebsd-current@ gab es ja in den letzten Wochen einen sehr langen Thread, eigentlich einen ganz klassischen Bikeshed über die Frage, was nun mit GCC passieren soll. Soll FreeBSD-GCC (ich würde den GCC im FreeBSD-Basissystem inzwischen als Fork bezeichnen) auf allen Plattformen mit Clang als Standard nur noch optional gebaut werden, ganz entfernt werden, zumindest g++ deaktiviert werden? Dabei ging es auch um die Frage "Ist Clang reif genug?" und "Sind neuere GCC-Versionen reif genug?". Wir werden sehen, wie man am Ende entscheidet.

Ich verstehe auch den Wunsch einiger OpenBSD-Entwickler einen zu 100% zuverlässigen Compiler zu haben. Wer hat den nicht? Aber auch wenn ich nichts von Compilern verstehe, habe ich etwas Ahnung von Softwareentwicklung. Und die sagt mir, dass sowohl GCC als auch Clang so komplex sind, dass sie gar nicht fehlerfrei sein können. Clang oder GCC zu forken und als LTS-Version zu führen ist naiv, das es nicht funktioniert sehen wir doch mit FreeBSD-GCC wo nun wirklich viel reingebuttert wurde. Dadurch sinkt weder die Komplexität, noch die Fehleranfälligkeit. Eher im Gegenteil, durch den nur noch eingeschränkten Nutzerkreis übersieht man Bugs noch viel eher als im Hauptprojekt.

Vor einigen Jahren wurde mal PCC durch das Dorf getrieben, als einfacher C99-Compiler sollte er zuverlässig und schnell (im Sinne der Compile-Zeiten) sein. Das war eine durchaus interessante Idee, aber am Ende ist sie doch wieder eingeschlafen. Auch wenn noch welche an PCC zu frickeln scheinen, ist er nach wie vor nicht in der Lage den meisten meines Codes zu bauen. Er stürzt ab, läuft in Endlosschleifen, gibt seltsame Fehlermeldungen. Wenn was herausfällt, funktioniert es meist nicht. Andere Versuche wie z.B. TCC sind ebenfalls wieder eingeschlafen oder waren nie benutzbar. Einen nutzbaren Compiler zu schreiben, ist wohl nichts, was man mal nebenbei macht.

Daher bleibt realistisch gesehen nur deine Lösung: Mehrere Compiler nutzen. Ich mache das ebenfalls, derzeit gcc47, gcc47 und clang 3.3. FreeBSD wird es ab 10.0 auch unterstützen das Basissystem ohne zu viel Gefrickel mit einem beliebigen Compiler zu bauen. Sofern er mit den Code klarkommt. Vielleicht wäre das auch eine Idee für OpenBSD, sofern es dort noch nicht möglich ist. Einfach externe Toolchains erlauben.
 
Moin,

meiner Meinung nach, ließe sich ein Compiler mit LTS machen. Allerdings müssen Bedingungen erfüllt werden, die konträr zur heute grassierenden Feature-Sucht wirken und damit die Komplexität weiter erhöhen:
  • "hippe" Spracherweiterungen müssen tabu bleiben
  • Performance-Tuning muss tabu bleiben
  • "Super-Tuning" des Optimierers und durch diesen ist ebenfalls tabu
  • konsequentes Beseitigen von Fehlern

Außerdem denke ich, wenn man die "Fork-Richtung" mal umkehren würde, ließe sich ebenfalls eine LTS-Version eines Compiler bauen. Ich meine damit, dass man vom LTS-Compiler einen Ableger mit neuen Features bildet. Da ich auch kein Compiler-Experte bin, sind das nur mal so meine - vielleicht spinnerten - Gedanken.

Grundsätzlich gebe ich Euch Recht, dass man nach dem jetzigen Stand eine LTS-Version nicht bauen kann und dass man mehrere Compiler durchprobieren muss, bis man für sein Projekt einen zuverlässigen Compiler gefunden hat.

JueDan
 
Alle Jahre wieder... ist das nicht ein Grundsatz in der Informatik: "Das muss neu geschrieben werden!"

Für mich ist LTS hauptsächlich: Schimmelt langsam vor sich hin, bis keiner den Saustall mehr aufräumen will. In Informatik: Wenn dann mal ein Upgrade kommt, ist das Geschrei groß, weil dank großem Clusterfuck gar nichts mehr geht. Ein Beispiel ist Windows, wenn dann unter Window 8 die Windows 98 Anwendung plötzlich nicht mehr starten will... lief ja bisher immer, also warum was tun?

Klar, Bugs gibt es immer. Aber damit muss man halt klarkommen. Und dann hat man über Jahre scheißcode geschrieben, den die LTS-Version gefressen hat, aber mit der neuen LTS-Version geht's nicht mehr, weil er strikter ist. Oder man macht nie wieder Updates. Ist ja nicht so, als wenn Compiler das einzige Stück Software in der Kette von möglichen Bugs ist
 
Kamikaze schrieb:
[...]. Aus dieser Erfahrung kann ich den Wunsch nach einem zuverlässigen Compiler voll nachvollziehen.

Damit meine Stellungnahme da nicht so in der Luft hängt, wie seht ihr das?
Zum Vergrößern anklicken....

so dazu bedarf es einen Compilergenerator und echte Compilergenerierung noch Forschungsgebiet, in Einzelfällen ist das gelungen, diese verspricht vor allem Vorteile bei der Korrektheit des generierten Compilers und die Einsparung aufwendiger,fehleranfälliger Programmierarbeit beim manuellen oder teilautomatischen Erstellen eines Compilers.Parser und Scannergeneratoren können nur Teile eines Compilers erstellen...

Werkzeuge Input :

http://www.cs.hs-rm.de/~weber/comp/vorlesung/kap9.pdf

Hochkomplex das ganze :

https://www.amazon.de/Compilerbau-Einführung-angewandten-Mathematik-Studienbücher/dp/3519323389

Bisschen moderner das Standard werk ;)

https://www.amazon.de/Compiler-Prinzipien-Techniken-Werkzeuge-Pearson/dp/3827370973
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben