Hier gibt es ein Interview mit David I:

http://www.itwriting.com/blog/5966-e...-versions.html

Zusammenfassend kann man sagen, dass die beiden Compiler (Delphi und C++) völlig neu gemacht werden. Delphi bekommt eine neuere (modernere) Sprache und einen neuen Codegenerator (basierend auf LLVM). Analoges gilt für C++Builder.

Damit soll die Codequalität sich verbessern und weitere Plattformen und CPUen schneller zur Verfügung stehen.

Bin mal gespannt, ob auch Smart Linking verbessert wird oder ob Delphi dann nur noch 20 MB große EXEs für ein Programm mit einem leeren Form ausspuckt… Da lob ich mir doch das schlanke D5, das mit Actions, Tnt Controls und ThemeManager fast alles kann.

Zitat von evilboy:

Bin mal gespannt, ob auch Smart Linking verbessert wird

Das muss nicht verbessert werden. Der Linker kann nichts dafür, dass jede popelige Funktion der RTL, VCL und FMX gleich den ganzen Rattenschwanz mit sich zieht. Von Interfaces hat da wohl noch niemand was gehört, oder dass es Klassenkonstruktoren gibt. Warum muss TStream denn das gesamte DFM-Streaming mit sich mitbringen. Ist in einer VCL Anwendung vielleicht nicht unnötig aber ein Konsolen-Programm braucht das eher selten...

Klassenkonstruktoren gibt es allerdings erst seit ein paar Versionen... Was sollten Interfaces beim Beispiel Streams/DFM denn bringen? Irgendwo muss das Interface ja implementiert werden... Es würde eigentlich schon reichen, das DFM-Zeug in eine eigene Klasse auszulagern wie es sich gehört.

Ich denke, ein Neuschreiben des Compilers war langsam aber sicher an der Zeit. Wenn man nur mal die endlosen internen Compilerfehler bedenkt und sich überlegt, wie alt die Codebasis im Grunde ist und wie oft sie schon aufgebohrt wurde, kann man sich ausmalen, was das unter der Haube für ein Gefrickel sein muss inzwischen.

Ich bin gespannt, ob mit dem neuen Compiler endlich auch Forward-Deklarationen überflüssig werden bzw. endlich die Konstrukte möglich werden, die mit dem Single-Pass-Compiler aktuell nicht gehen.

Zitat von jbg:

oder dass es Klassenkonstruktoren gibt. Warum muss TStream denn das gesamte DFM-Streaming mit sich mitbringen.

Joar, wenn die "einfach" das ganze Initializitation-Zeugs in die Klassenkonstruktoren verschieben, alles erst initialisieren, wenn es das Erste mal wirklich benutzt wirde und in den (Klassen)Konstructoren/Destruktoren auf nichts zugreifen (außer über TObject oder über Interfaces), was nicht nötig ist, dann würde das Ganze Zusatzzeug auch nicht mit gelinkt, wenn man z.B. keine VCL benutzt.

Zitat von Insider2004:

Zusammenfassend kann man sagen, dass die beiden Compiler (Delphi und C++) völlig neu gemacht werden. Delphi bekommt eine neuere (modernere) Sprache und einen neuen Codegenerator (basierend auf LLVM). Analoges gilt für C++Builder.

Kann mich mal jemand aufklären, was das bedeutet? ich kenne mich mit Compilerbau nicht so aus.

LLVM bedeuete ein ähnlich tröges Laufzeitverhalten wie Java und C# ??

hier gibt es auch noch was zum Weiterlesen

http://www.delphipraxis.net/168752-llvm-und-delphi.html


ich dachte LLVM bietet mehr Möglichkeiten den Code besser auf meine Zielplattform anzupassen und der Code wird damit schneller

Zitat von Luckie:

Zitat von Insider2004:

Zusammenfassend kann man sagen, dass die beiden Compiler (Delphi und C++) völlig neu gemacht werden. Delphi bekommt eine neuere (modernere) Sprache und einen neuen Codegenerator (basierend auf LLVM). Analoges gilt für C++Builder.

Kann mich mal jemand aufklären, was das bedeutet? ich kenne mich mit Compilerbau nicht so aus.

Das bedeutet, dass das Frontend Daten erzeugt, die LLVM dann als Backend in Binärcode verwandelt. Bisher hat Embarcadero ja dafür eine eigene Lösung benutzt, aber das bedeutet natürlich auch, dass für jede Plattform eine solche eigene Lösung notwendig ist.
Durch LLVM genügt es, wenn der Code in damit kompatiblen Zwischencode verwandelt wird. Die eigentlichen Binärdaten für die gewünschte Plattform werden dann von LLVM erzeugt.

Heißt:
Es genügt, wenn eine neue Plattform für LLVM verfügbar ist, man muss sie nicht selbst implementieren.

Das heißt natürlich nicht, dass dafür nichts mehr gemacht werden muss, aber es genügt ein Framework, das auf dem eigentlichen Maschinencode für die Plattform aufbaut. Und darauf möchte man sich konzentrieren. Wenn das gut funktioniert, inkl. debuggen usw., ist das sehr interessant.

Wie das mit Inline-Assembler usw. aussieht, frage ich mich dabei allerdings schon. Der kann ja nicht allgemeingültig sein, d.h. der muss dann irgendwie durchgeschleust werden. Dafür gibt es in LLVM sicher Möglichkeiten, aber ob man das dann genauso gut debuggen kann? Ich habe keine Ahnung. Aber ich hoffe es mal.

Zitat von Bummi:

LLVM bedeuete ein ähnlich tröges Laufzeitverhalten wie Java und C# ??

Nein! Der Name lässt es vermuten. Es ist aber nicht so. Aber das Konzept ist ähnlich. LLVM ist keine langsame Virtual Machine wie bei C# oder Java. LLVM ist nur eine Toolkette oder Compiler-Konzept. es erfolgt alles zur Compile-Zeit und nicht zur Laufzeit.

Emba erzeugt jetzt nur noch eine Art Zwischencode, der vom LLVM "weiterverarbeitet" wird. Die ganze Arbeit mit den Plattformen und CPUen überlässt man den LLVM-Leuten. Das geht schneller, da neue Plattformen schneller durch das Projekt zur Verfügung stehen und man nicht immer erst selber Nachentwickeln muss.

Erstmalig wird das wohl beim 64-bit C++ Compiler gemacht werden, weil da Emba ja noch gar nichts hatte. Ich könnte mir auch vorstellen, dass der Delphi Compiler erst mal so gelassen wird, wie er ist und nur einen Compiler-Switch bekommt, der wenn gesetzt, LLVM-Code auswirft und keine EXE.