Neue Delphi/C++ Compiler in Planung

[Insider2004]

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.

[evilboy]

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.

[jbg]

Zitat:

Zitat von evilboy (Beitrag 1173861)

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...

[Namenloser]

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.

[himitsu]

Zitat:

Zitat von jbg (Beitrag 1173865)

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.

[Luckie]

Zitat:

Zitat von Insider2004 (Beitrag 1173757)

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.

[Bummi]

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

[bernhard_LA]

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

[jaenicke]

Zitat:

Zitat von Luckie (Beitrag 1173875)

Zitat:

Zitat von Insider2004 (Beitrag 1173757)

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. :wink:

[Insider2004]

Zitat:

Zitat von Bummi (Beitrag 1173876)

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.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1173882)

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. :wink:

Ich kann mir nicht vorstellen, das man ernsthaft dieses LLVM-Konzept verfolgt und gleichzeitig Assembler zulässt. Das kann doch gar nicht zusammen funktionieren bzw. muss zu unerwünschten Effekten kommen: Wenn ich meine Anwendung durch ASM so gepimpt habe, das sie gerade mal funktioniert, dann werde ich aber sowas von gegen die Wand fahren, wenn ich das auf einer anderen Plattform ausführe.

Aber, stimmt schon: Das ist ja nicht Embas Problem, sondern das vom Programmierer.

[Insider2004]

Zitat:

Zitat von Furtbichler (Beitrag 1173885)

Zitat:

Zitat von jaenicke (Beitrag 1173882)

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. :wink:

Ich kann mir nicht vorstellen, das man ernsthaft dieses LLVM-Konzept verfolgt und gleichzeitig Assembler zulässt. Das kann doch gar nicht zusammen funktionieren bzw. muss zu unerwünschten Effekten kommen: Wenn ich meine Anwendung durch ASM so gepimpt habe, das sie gerade mal funktioniert, dann werde ich aber sowas von gegen die Wand fahren, wenn ich das auf einer anderen Plattform ausführe.

Aber, stimmt schon: Das ist ja nicht Embas Problem, sondern das vom Programmierer.

Wie schon immer: Assembler ist der Feind von Multiplatforming. Sobald ein neuer Prozessor/Betriebssystem rauskommt kann man sein Assembler-Werk entsorgen / neu schreiben.

Ich persönlich habe alle meine Asm-Teile rausgeworfen. Macht zu viel Ärger und Arbeit.

[mkinzler]

Aber nicht jedem ist die Unterstützung mehrere Plattformen bzw. Prozessoren wichtig. Zudem war die Abwärtskompatibilität bei Delphi immer wichtig.

[Insider2004]

Zitat:

Zitat von mkinzler (Beitrag 1173890)

Aber nicht jedem ist die Unterstützung mehrere Plattformen bzw. Prozessoren wichtig. Zudem war die Abwärtskompatibilität bei Delphi immer wichtig.

Das liegt gar nicht in deiner Hand. Das fängt schon mit Win32 und Win64 an.

[jaenicke]

Der Assemblercode für die entsprechende Plattform muss dann natürlich auch vorhanden sein. Automatisch für andere Plattformen oder so geht logischerweise nicht.

[Chemiker]

Hallo,

wobei der Geschwindigkeitsvorteil bei Assembler nicht mehr so groß ist gegenüber Pascal-Code, wie in den zurückliegenden Jahren.

Bis bald Chemiker

[mquadrat]

Das Inline-Assembler rausfliegt ist ja abzusehen. Geht ja mit dem neuen Cross-Plattform Ansatz in XE2 jetzt schon nicht mehr so wahnsinnig gut. Und ganz im Ernst: Entweder ich programmier ne Hochsprache oder eben nicht. Dieses Mischen fand ich schon immer seltsam.

[jaenicke]

Ganz wird es wohl kaum herausfliegen. Dafür müsste man viel mehr Funktionalität in den Compiler stopfen. Und selbst wenn man das wollte würde das schwierig werden.

Denn ganz ohne Assembler lassen sich einige Funktionen schlicht nicht umsetzen. Ein Beispiel dafür sind allgemeine Aufrufe von Funktionen mit beliebigen Parametern. Da wird zwar schon viel mit Pascal gemacht, aber eben nicht alles, siehe bei XE z.B. die Funktion RawInvoke aus der Unit Rtti. Diese wird benutzt um mit Angabe der Aufrufkonvention und der Parameter beliebige Funktionen aufzurufen.

Viel ist es allerdings nicht, das sich mit purem Object Pascal (derzeit) nicht/schlecht umsetzen lässt. Wobei ich nicht geschaut habe wie das in XE2 aussieht.

[Namenloser]

Vielleicht kann man ja LLVM-Code inline-assemblieren (was dann natürlich in Maschinencode für die jeweilige Plattform übersetzt wird)? Hardwarenahe Optimierung wäre damit dann zwar nicht oder nur sehr begrenzt möglich, aber sowas wie RawInvoke könnte man damit schon umsetzen.

[BUG]

Es ist ja nicht so, als ob llvm-Compiler keinen inline-Assembler unterstützen könnten. Clang ist da annähernd gcc-compatibel.

Btw: Clang ist ein genialer C/C++ Compiler und das Ausprobieren lohnt sich schon für die besseren Fehlermeldungen im Vergleich zum gcc :thumb:

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1174032)

Denn ganz ohne Assembler lassen sich einige Funktionen schlicht nicht umsetzen. Ein Beispiel dafür sind allgemeine Aufrufe von Funktionen mit beliebigen Parametern.

Sollte man nicht anfangen, saubere Programme zu schreiben? ;-) (Ist nicht auf dich gerichtet)

Nicht alles, was technisch machbar ist, ist auch gut. Wenn Emba hier selbst noch pfuscht ist das doch kein Grund.

Einige Dinge werden wohl noch für einige Zeit mit Assembler besser (weil performanter) umzusetzen sein. Aber dann werden sich die Programmierer die Mühe machen müssen, die entsprechenden Implementierungen im Code vorzusehen bzw. für die einzelnen Plattformen gepimpte Libraries zu entwickeln.

[jaenicke]

Ich benutze das für eine proprietär implementierte Skriptsprache inkl. Debugger usw., und da fällt mir schlicht für einiges keine Möglichkeit ein das ohne Assembler zu machen.

Wie würdest du denn den Aufruf einer DLL-Funktion aus einem interpretierten Skript heraus ohne Assembler machen? :gruebel: Du klingst ja so als gebe es für alles Alternativen, aber da fällt mir keine ein. Und das ist z.B. eine Anwendungsmöglichkeit des Beispiels, das ich genannt hatte.

[himitsu]

Wobei du für den Aufruf auch die neue RTTI nutzen könntest.
(Man muß nicht direkt auf eine TypeInfo gehn, sondern kann sich dieses auch manuell zusammenbauen und dann deren Methoden benutzen)

[Luckie]

Das heißt aber doch auch, dass das entsprechende "Framework" (?) auf dem Zielsystem vorhanden sein muss oder wie kann ich mir die Funktionsweise vorstellen?

[Medium]

Ich glaube das LLVM Backend ist nur eine Hand voll KiB groß. Das sollte, ähnlich wie damals der BASIC Interpreter, problemlos mit ins Executable passen. (Kleiner als der VCL-Ballast wird ja nicht sooo schwer :))

[mkinzler]

Es sollte gar nicht Teil der EXE werden. Ist ja nur ein Zwischencode

Code:

Delphi                                               Win32
C++         -> LLVM-Zwischencode  -> LLVM Backend -> Win64
Objective C                                          OSX32
                                                     OSX64
                                                     iOS 
                                                     ...

[Insider2004]

Zitat:

Zitat von mkinzler (Beitrag 1174182)

Es sollte gar nicht Teil der EXE werden. Ist ja nur ein Zwischencode

Code:

Delphi                                               Win32
C++         -> LLVM-Zwischencode  -> LLVM Backend -> Win64
Objective C                                          OSX32
                                                     OSX64
                                                     iOS 
                                                     ...

Sehe ich auch so. LLVM ist nur eine Abbildungsvorschrift.

[Medium]

Schon, aber wenn da das Backend grade mal ~40KiB groß ist (ich meine dieser Wert war auf der Wikipedia dafür angegeben) 20KiB schlank ist, dann würde ein Einkompilieren eine separate Installation beim Kunden quasi zum Nulltarif vermeiden. Sollte man aber einstellbar machen, ob man das will! Sonst weint wieder einer :mrgreen:

[Namenloser]

Aber wozu sollte der Kunde das Backend brauchen? :gruebel:

[implementation]

Damit LLVM besser optimieren kann, denn nur dann kennt der Optimizer ja die genaue CPU. Daraus könnte man dann evtl. eine JIT-Kompilierung basteln.

[Medium]

Hmm, ich dachte hier vermutlich eine Spur zu X-Platform :) (Passiert mir auch eher selten. Ich werd alt...)

[Namenloser]

Zitat:

Zitat von implementation (Beitrag 1174250)

Damit LLVM besser optimieren kann, denn nur dann kennt der Optimizer ja die genaue CPU.

Na gut... aber brauchen wir wirklich noch eine weitere Managed-Laufzeit-Umgebung? Haben wir mit .net und JVM nicht schon genug?

Aber gut, wenn das Backend schnell und klein genug ist hätte ich grundsätzlich nichts dagegen... ich glaube aber nicht, dass Embarcadero das so löst.

[Medium]

Wenn es besser wäre: Nein ;) (Und wirklich managed ist das ja nu nicht. Es wird lediglich bytecode mit Compiler geliefert - managed beinhaltet da ja etwas mehr.)

Edit: Und "besser" wäre es ja schon dadurch, wenn es mal in Delphi schreibbar wäre!
Edit2: Und bei der Größe ohne großes Getöse mal eben mitzuliefern wäre, im Gegensatz zur CLR und JVM.