Neue Delphi/C++ Compiler in Planung

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

[Furtbichler]

Zitat von jaenicke:

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.

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 von Furtbichler:

Zitat von jaenicke:

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.

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 von mkinzler:

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.

[Insider2004]

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.