In welcher Programmiersprache wurden gängige C++ Compiler geschrieben?



  • Hi,

    mich würde interessieren, in welcher Programmiersprache gängige C++ Compiler geschrieben wurden?



  • Der Gnu Compiler gcc war ursprünglich in C geschrieben, wobei es jetzt immer mehr Richtung C++ geht.
    Grundsätzlich kann man aber jede Sprach für Compiler nehmen. Kannst auch in Python machen wennst lustig bist.



  • Cccccompiler schrieb:

    Grundsätzlich kann man aber jede Sprach für Compiler nehmen. Kannst auch in Python machen wennst lustig bist.

    Wenn du aber einen C++-Compiler in Python schreibst, solltest du pro Build ein paar Wochen einkalkulieren 😞



  • Cccccompiler schrieb:

    Der Gnu Compiler gcc war ursprünglich in C geschrieben, wobei es jetzt immer mehr Richtung C++ geht.
    Grundsätzlich kann man aber jede Sprach für Compiler nehmen. Kannst auch in Python machen wennst lustig bist.

    Seit 2011 oder 2012 wurde der komplett auf C++ umgestellt.


  • Mod

    Tatsächlich sind überraschend viele Compiler in der Sprache geschrieben, die sie übersetzen. Und da sich nun eine Frage bezüglich Hühnern und Eiern aufdrängt, gibt's dazu noch einen Link:
    https://en.wikipedia.org/wiki/Bootstrapping_(compilers)



  • Interessant, ich frage mich, warum man Compiler nicht in Assembler schreibt.
    Theoretisch sollte die Hardwarenähe doch für die beste Performance sorgen.



  • fdjafdjad schrieb:

    Interessant, ich frage mich, warum man Compiler nicht in Assembler schreibt.
    Theoretisch sollte die Hardwarenähe doch für die beste Performance sorgen.

    Aus dem gleichen Grund, aus dem man alle anderen Programme ebenfalls nicht in Assembler schreibt.



  • fdjafdjad schrieb:

    Interessant, ich frage mich, warum man Compiler nicht in Assembler schreibt.
    Theoretisch sollte die Hardwarenähe doch für die beste Performance sorgen.

    Nicht wirklich. Es ist sehr schwierig, die Rechenwerte moeglichst effizient auf die Register zu verteilen und Rechenoperationen durch bitgefrickel zu ersetzen. Compiler sind dazu sehr gut in der Lage, Menschen eher weniger, sodass gerade bei groesseren Programmen Compiler besser sind als Menschen.
    Selbst wenn man Assembler schreibt, sind das deswegen normalerweise nur sehr kleine Funktionen, die aber bestimmte Features in einem Masse ausnutzen koennen, die der Optimierer nicht schafft. So ist der Compiler z.B. nicht immer in der Lage simd-instructions effizient auszunutzen, ein mitdenkender Assemblerprogrammierer schon eher.
    Daneben ist der Compiler auch nicht wirklich geschwindigkeitskritisch. Im Gegensatz zu Multimediaanwendungen kommt es nicht auf jedes einzelne Prozent an, sondern auf eine akzeptable Gesamtperformance.
    Ansonsten siehe manni66.



  • SeppJ schrieb:

    Tatsächlich sind überraschend viele Compiler in der Sprache geschrieben, die sie übersetzen. Und da sich nun eine Frage bezüglich Hühnern und Eiern aufdrängt,[...]

    wobei es hier wohl zwei Schwierigkeitsgrade gibt:

    a) der Compiler erzeugt Bytecode für eine Bytecode-VM
    b) der Compiler erzeugt Maschinencode

    im Fall a) ist es ein Anfang, die Bytecode-VM auf die Zielplattform zu portieren und dann den vorhandenen Bytecode des Compilers auf der Bytecode-VM der Zielplattform laufen zu lassen, von Anpassungen abgesehen.

    Die Frage hier war aber nach C++-Compilern, und da liegt die Sache etwas anders.
    Etwas schwieriger. Um einen in C++ geschriebenen Compiler zu bootstrappen, müßte man auf der Zielplattform ja eigentlich bereits einen C++ Compiler haben. D.h. man fängt beispielsweise mit einem einfachen Compiler für eine Teilmenge (sagen wir, C) an, transcompiliert den Ziel-Compiler nach C (oder einer anderen Teilmenge der Zielsprache), und arbeitet sich dann von der Teilsprache auf ganz C++ hoch. Weiß jemand, ob das schon einmal gelungen ist (C++ bootstrappen) ?

    ps. Jetzt keine Diskussion, ob C eine Teilsprache von C++ ist und was "C/C++" zu bedeuten hat ... gähn ...



  • @großbuchstaben

    großbuchstaben schrieb:

    Die Frage hier war aber nach C++-Compilern, und da liegt die Sache etwas anders.
    Etwas schwieriger. Um einen in C++ geschriebenen Compiler zu bootstrappen, müßte man auf der Zielplattform ja eigentlich bereits einen C++ Compiler haben.

    Wieso sollte das nötig sein?
    Man braucht dazu bloss irgend einen C++ Compiler auf irgend einer Plattform.



  • fdjafdjad schrieb:

    Interessant, ich frage mich, warum man Compiler nicht in Assembler schreibt.
    Theoretisch sollte die Hardwarenähe doch für die beste Performance sorgen.

    Du musst unterscheiden, zwischen der Geschwindigkeit des Compilers und der Geschwindigkeit des erzeugten Codes. Die sind tatsächlich völlig unabhängig. Du könntest mit PHP einen C++ Compiler schreiben, der hoch optimierten Code erzeugt. Die Compilezeiten sind wahrscheinlich nicht die besten.

    großbuchstaben schrieb:

    Die Frage hier war aber nach C++-Compilern, und da liegt die Sache etwas anders.
    Etwas schwieriger. Um einen in C++ geschriebenen Compiler zu bootstrappen, müßte man auf der Zielplattform ja eigentlich bereits einen C++ Compiler haben. D.h. man fängt beispielsweise mit einem einfachen Compiler für eine Teilmenge (sagen wir, C) an, transcompiliert den Ziel-Compiler nach C (oder einer anderen Teilmenge der Zielsprache), und arbeitet sich dann von der Teilsprache auf ganz C++ hoch. Weiß jemand, ob das schon einmal gelungen ist (C++ bootstrappen) ?

    hustbaer hat es ja schon angedeutet. Man braucht tatsächlich keinen C++-Compiler auf der Zielplattform. Ich könnte beispielsweise auf einer x86-Plattform einen Compiler compilieren, der auf ARM läuft und auch Code für ARM produziert.



  • hustbaer schrieb:

    Wieso sollte das nötig sein?
    Man braucht dazu bloss irgend einen C++ Compiler auf irgend einer Plattform.

    eben. Den hat man aber am Anfang nicht. Einer ist immer der erste - das Huhn-Ei-Problem.

    Dann muß man sich im schlimmsten Fall (wenn auch kein C-Compiler auf der Zielplattform vorliegt, oder der Zielcompiler nicht in C transcompiliert werden kann) "aus dem Nichts" hocharbeiten

    - erst einen Minimal-Compiler für eine Mini-Sprache (nennen wir sie "MS1") in Assembler herstellen, in der man zum Beispiel nur Zeichen einlesen kann und Speicher für Variablen belegen kann.

    - dann einen Compiler für eine etwas mächtigere Mini-Sprache "MS2" in MS1 programmieren; MS2 könnte dann z.B. alles, was MS1 kann, plus arithmetische Ausdrücke auswerten plus Zeichen ausgeben

    - dann einen Compiler für eine noch etwas mächtieger Sprache "MS3", der in MS2 geschrieben ist, und wieder etwas mehr kann - z.B. alles das, was MS2 kann plus Funktionsdefinitionen plus struct.

    - usw.

    Einfacher wird es, wenn man auf der Zielplattform schon einen C-Compiler hat und den in C++ geschriebenen C++-Compiler (das war ja unser Ausgangspunkt) in C transcompilieren könnte.

    Jedenfalls scheint mir ein solches Bootstrapping von Sprachen, die auf Maschinencode compilieren, typischerweise komplizierter als wenn man "nur" eine Bytecode-VM auf die Zielplattform portieren muß, weil der Zielcompiler bereits im Bytecode vorliegt (von Anpassungen an die Zielplattform mal abgesehen).



  • großbuchstaben schrieb:

    hustbaer schrieb:

    Wieso sollte das nötig sein?
    Man braucht dazu bloss irgend einen C++ Compiler auf irgend einer Plattform.

    eben. Den hat man aber am Anfang nicht. Einer ist immer der erste - das Huhn-Ei-Problem.

    Stroustup hat seinen C++ (bzw C with Classes) Compiler damals in C geschrieben. Der g++ wurde am Anfang ebenfalls in C geschrieben, aber sobald man einmal einen anpassbaren Compiler hat, macht es viel weniger Arbeit, nur das Backend fuer die neue Plattform zu schreiben und nicht den ganzen Compiler. Das Henne-Ei-Problem stellte sich also nur frueher mal.

    Bei Bytecode-VMs muss man den Bytecodeinterpreter ebenso fuer die neue Plattform compilen und kann danach darauf aufbauen. Wenn der Compiler in eben dieser Sprache geschrieben ist, ist der kein Problem, aber vermutlich sind recht oft auch die Bytecodecompiler aus Geschwindigkeitsgruenden in nativer Sprache.



  • wir reden hier von bootstrapping - was du schreibst, liest sich eher nach cross-compiling oder Portierung.


  • Mod

    großbuchstaben schrieb:

    wir reden hier von bootstrapping - was du schreibst, liest sich eher nach cross-compiling oder Portierung.

    Es wird sicher irgendwann mal jemand* gemacht haben. Als Studienprojekt in angewandter Informatik oder ähnliches. Oder einfach, weil es interessant ist. Aber eben niemals ernsthaft im Auftrag irgendeines bekannten Projektes. Eben weil es nicht nötig ist.

    Die meisten werden vermutlich bei einem C-Compiler und Übersetzung des Linux-Kernels aufgehört haben (weil das eben die klassische Herausforderung ist), aber wo man einen C-Compiler hat, kann man sich ja auch ganz einfach einen C++-Compiler machen, weil es in C geschriebene C++-Compiler gibt.

    Und natürlich wurde das ganze wenigstens einmal in der Geschichte auch ernsthaft gemacht, sonst könntest du deinen Rechner nicht so nutzen, wie du es jetzt gerade tust. Die Kette war aber deutlich länger als Maschinensprache -> C -> C++.

    *: Vermutlich sogar viele.



  • SeppJ schrieb:

    großbuchstaben schrieb:

    wir reden hier von bootstrapping - was du schreibst, liest sich eher nach cross-compiling oder Portierung.

    Es wird sicher irgendwann mal jemand* gemacht haben. Als Studienprojekt in angewandter Informatik oder ähnliches. Oder einfach, weil es interessant ist. Aber eben niemals ernsthaft im Auftrag irgendeines bekannten Projektes. Eben weil es nicht nötig ist.

    *: Vermutlich sogar viele.

    hängt von der Sprache ab.

    Bei Forth ist bootstrapping ziemlich verbreitet (man implementiert einige Befehle und einen threaded-code Mechanismus in Assembler und formuliert dann immer größere und mächtigere Befehlsmengen in der jeweils vorangehenden Iteration, bis zu einem "ausgewachsenen" Forth-System samt interpreter und Compiler).

    der Smalltalk-Dialekt squeak wurde auch ge-bootstrap-t - die Bytecode-VM wurde in einem Smalltalk-Dialekt "Slang" formuliert, der sich in C übersetzen ließ und damit auf der Zielplattform, vermutlich nach einigen Plattform-spezifischen Anpassungen, compilieren ließ. Lief die VM dann auf der Zielplattform, konnte man ein Image von der Quellplattform übertragen und hatte letzendlich ein Smalltalk-System auf der Zielplattform. Eine "Replikation" der besonderen Art, da der Programmtext der VM in der Zielsprache selbst (genauer einer Teilmenge davon) formuliert werden kann.



  • @großbuchstaben
    Du vermischt hier gerade zwei Sachen, je nachdem wie es dir gerade reinpasst.

    1. Ein neuer Compiler für eine existierende Sprache X, der in Sprache X geschrieben ist, für die es bereits bestehende Compiler gibt.
      Das löst man nicht über "Bootstrapping", weil es bescheuert aufwendig wäre.
      Das löst man indem man den neuen Compiler mit einem bestehenden übersetzt, und danach dann mit sich selbst übersetzt.

    2. Ein Compiler für eine neue Sprache, für den es noch überhaupt keine Compiler gibt.
      Hierbei ist die Aufgabe nicht den Compiler auf einer neuen Plattform zum Laufen zu bringen, sondern ihn überhaupt mal zum Laufen zu bringen. Was natürlich schwer ist, wenn der Compiler in "seiner eigenen" Sprache geschrieben ist. Nur hier hast du das von dir angesprochene Henne/Ei Problem.
      Das löst man normalerweise indem man den ersten Compiler für Sprache Y in einer anderen Sprache X schreibt, wobei man für X eben schon fertige Compiler hat.
      Danach schreibt man den Compiler einfach neu in Sprache Y.
      Auch hier wäre es normalerweise ziemlich sinnfrei es über "Bootstrapping" zu machen.

    Schon alleine deswegen, weil sich die Regeln neuer Sprachen oft noch ändern, lange nachdem man die ersten Experimente mit dem ersten Compiler machen möchte. D.h. man müsste den "in seiner eigenen Sprache geschriebenen" Compiler, den man sich über Bootstrapping irgendwie erbastelt hat, permanent an die modifizierten Sprachregeln anpassen.

    Davon abgesehen finde ich es sehr anstrengend mit Leuten zu diskutieren die sich permanent "zurechtbiegen" über was "wir gerade reden", damit es zu ihren Argumenten passt.



  • Hi,

    Turbo C für Atari war der erste AnsiC compiler für Tos. Er war selbst auch in AnsiC und wurde daher zuerst mit Turbo C für Dos übersetzt. So bald der lief hat er sich selbst übersetzt und erzeugte so unter Dos den unter Tos lauffähigen Compiler.

    Mfg Martin



  • Ich habe z.b. für meine HP9000/385 davon abgesehen einen gnu compiler v3.3 erzeugen zu lassen, weil der c-compiler auf dem Rechner kein ANSI C konnte. Ich hätte mich durch eine Masse an Iterationen des gcc arbeiten müssen, was auf einem Computer mit 300MB Festplatte und einer 50MHz CPU wahrscheinlich Jahre bebötigt hätte, falls überhaupt möglich.

    Solange nicht in einem großen Knall alles restted wird haben wir eigentlich kein Problem damit einen C-Compiler auf ein beliebiges Target zu portieren.



  • hustbaer schrieb:

    @großbuchstaben
    Du vermischt hier gerade zwei Sachen, je nachdem wie es dir gerade reinpasst.

    ich habe von Anfang an gesagt, daß ich mich auf "bootstrapping" beziehe und nicht auf porting oder cross-compiling. EOF


Anmelden zum Antworten