Lazarus als IDE für LLVM (llvm-pascal)

[MitjaStachowiak]

Hallo,

wer beim letzten Forumtreffen dabei war, erinnert sich vielleicht, dass ich bereits Fragen in diese Richtung gestellt habe. Also LLVM ist ganz entfernt mit Java vergleichbar: Hochsprachen werden für eine RISC-Architektur kompiliert, für die es nicht unbedingt eine Mikroarchitektur (Hardware), sondern nur eine virtuelle Umgebung gibt. Innerhalb dieser Umgebung können Optimierungen, Debugging, etc. durchgeführt werden, dann wird das Ganze in einen bestimmten Assembler-Code für x86, amd64, ARM, usw. übersetzt.

Inzwischen kann von LLVM aus auch CUDA-Code generiert werden, also für GPU programming. Und genau hier hänge ich gerade: Ich soll mich für ein Proseminar an der TU mit CUDA beschäftigen. Dabei geht es mehr um die Hardwareimplementierung, aber trotzdem will ich wenigstens mal ein Beispielprogramm kompilieren und testen. Aber es geht einfach nicht! Für Windows wird man immer auf Visual Studio verwiesen, aber das kommt mir als OpenSource Programmierer gar nicht erst auf die Platte. Es gibt wohl eine Eclipse-Version für Cuda, aber nur auf Linux und Mac. Ich habe ewig versucht, auf Windows LLVM in Eclipse einzurichten, aber ohne Erfolg. Auch sonst scheint es keine richtige IDE für LLVM unter Windows zu geben.

Da habe ich natürlich gleich an Lazarus gedacht. Glücklicher Weise hat sogar schon jemand einen Pascal-Frontend für LLVM geschrieben (http://forum.lazarus.freepascal.org/ind ... ic=16535.0). Sieht aber so aus, als würde daran im Moment nicht gearbeitet... Außerdem ist die meiste Literatur dazu fremdsprachig, damit meine ich nicht in erster Linie Englisch, sondern auch Spanisch und Russisch. Ich habe erfolglos versucht, llvm-pascal als Compilerpfad bei Lazarus einzustellen, aber es wäre auch zu schön gewesen, wenn das so einfach ginge.

Ich werde wohl morgen Linux installieren und versuchen, CUDA dort zum laufen zu bringen.

Aber langfristig reizt mich die Idee, Lazarus auch für LLVM zu verwenden und ggf. die CUDA-Erweiterungen auch für Pascal zu entwickeln. Es ist nicht Ziel der Sache, Freepascal irgendwie Konkurrenz zu machen, ganz im Gegenteil: Angenommen es gelänge, Lazarus in Richtung LLVM zu erweitern, dann könnten sich Programmierer den komplizierten Eclipse-Einrichtungsmarathon ersparen und LLVM + Cuda + LazarusIDE inc. Freepascal in 10 Minuten installieren und benutzen, wie man es eben von Pascal gewohnt ist

Ich bin sicher, als einzige Multiplattform-IDE für Cuda könnte Lazarus erheblichen Zulauf finden.

Also wer eine Meinung dazu hat oder etwas neues von llvm-pascal hört, möge dies hier posten.
Eventuell würde ich dieses Projekt in nicht all zu ferner Zukunft in Angriff nehmen. Im Moment weiß ich noch zu wenig über Compilerbau und bin auch nicht mit der Entwicklung von Lazarus oder LLVM vertraut, weswegen ich gar nicht zu versuchen brauche, das als Bachelorarbeit zu machen, aber vielleicht im Master, oder einfach so...?

[mse]

Wo liegt das Problem? Mit MSEide geht die Einbindung beliebiger Compiler auf jeden Fall, z.B. verwende ich MSEide auch für Arbeiten an und mit MSElang welcher ebenfalls ein LLVM backend hat. Ich denke das sollte auch mit Lazarus möglich sein. Schwieriger ist der debugger falls nicht gdb verwendet werden kann.

[MitjaStachowiak]

Ich denke auch, dass zumindest die Compilierung mit einem anderen Compiler möglich ist. Nur einfach einen anderen Compilerpfad zu verwenden reicht nicht. Da stimmen zum Beispiel die Parameter nicht. Wenn ich in den Projekteinstellungen unter Compiler-Kommandos bei Compiler als Befehl "D:\Programme\LLVM\bin\clang++.exe" einstelle (Was sowieso eine doofe Idee ist, da clang++ für c++ und nicht für Pascal ist), kommt als Fehler "clang++.exe: error: unknown argument: '-vewnhi'". llvm-pascal macht irgendwie gar nichts.

Wer weiß, wie es besser geht?

[mse]

Vermutlich musst du alle FPC Optionen abschalten. Mit MSEide ist das einfach, weil es dort gar keine "Häkchen Dialog-Optionen" gibt. Ich glaube nicht, dass llvm-pascal einsatzbereit ist.

[MitjaStachowiak]

Ich denke auch, über ein Kommandline-Programm ohne Nennenswerte Uses-Liste geht llvm-pascal im Moment nicht hinaus. Bis an eine Entwicklung von Pascalprogrammen über LLVM, also mit Includes, Ressourcen, DLLs, Debugging, etc. zu denken ist, müssen Jahre an Entwicklung investiert werden.

Aber bin ich der Einzige, der das nutzen wollen würde?

[mse]

Bevor ich mit MSElang startete habe ich llvm-pascal angeschaut. Ich glaube es ist eher eine Studienarbeit mit unrealistischen Erwartungen bezüglich der Entwicklungszeit. Übrigens MSElang ist hier:
https://gitorious.org/mseide-msegui/pages/Mselang
https://gitorious.org/mseide-msegui/mselang/source

[MitjaStachowiak]

Ja, habe ich auch schon rein geschaut, aber nimm's mir nicht übel, dass das nur ganz grob war. Im Moment habe ich einfach zu viel zu tun. Ich hoffe ich komme in der Weihnachtspause weiter...

[MitjaStachowiak]

Hmm, sehe ich das richtig, dass man, anstatt den Weg von llvm-Pascal zu gehen und einen neuen Pascal-Parser für den LLVM-Compiler zu schreiben, auch einfach Freepascal, oder deinen MSE-Compiler direkt Code für die LLVM-Architektur erzeugen lassen kann?

Die soll ja so ähnlich sein, wie ARM. Wenn ich das richtig verstanden habe, wäre das dann ein normales Cross-Compiling, von x86-Windows nach LLVM. Und von da aus dann später wieder nach x86-Windows, was aber LLVM erledigen würde. Weil dann bräuchte man sich wegen Multi-Compilereinbindung oder Debugger keine Gedanken machen.

Gibt es für LLVM-Programme auch so eine Art Runtime, bevor diese in x86 oder was auch immer übersetzt werden? Das stelle ich mir schwierig vor, wenn das Programm auf Windows-API oder ähnliches zugreift...

[marcov]

Was ich davon weiß:

Jonas hat vor ein paar Jahre das LLVM Backend (originel in http://svn.freepascal.org/cgi-bin/viewv ... ches/llvm/ wie in oberere LLVM-Pascal Thread genannt) entwickelt, und danach hat er an JVM Unterstützung gearbeitet .

Während dieser JVM Backend Implementierung ist der Codegenerator umgeschrieben, aufgeteilt in ein mehr Lowlevel Teil und ein Highlevel Teil (hlcg).

Das LLVM Backend ist danach teilweise reimplementiert worden um hlcg zu nutzen. (ich glaube in ein privates GIT repo). Dies ist einer der Branches die hoffentlich in die kommende Monate in Trunk integriert werden sollen. (Das ist bis heute nicht getan um die Stabilisierung von 3.0 nicht zu gefährden, aber seit eine Woche sind 3.0 und Trunk getrennt)

Aber man muss vorsichtig sein um das LLVM backend zu verwirren mit Exoten wie Cuda oder die RadeonSI Backends. Typisch kann man generelle Code nicht für diese Backends kompilieren. Das funktioniert nur für spezielle Code mit Sprach Extensionen.

Das LLVM Backend ist mehr gemeint um Zugang zu mehr Architekturen zu bekommen.

Es ist schon einige Interesse in parallele Verwaltung, aber das geht eher in die Richtung ohne speziell Hardware, wie OpenMP

[MitjaStachowiak]

Dаз ist sehr interessant und sicher eine der ersten Adressen, die ich aufsuchen werde, wenn ich weiter an der Sache arbeite.

Also LLVM Backend bedeutet doch, einen Compiler zu schreiben, der den LLVM-Code in eine existierende Prozessorarchitektur übersetzt. An dieser Stelle hätte das doch erst mal nichts mit Pascal zu tun

Und was Cuda betrifft: Das zieht sich ja durch alle Ebenen, also selbst die Programmiersprache wird um zusätzliche Befehle erweitert. Wenn aber deren Compiler erst mal nur LLVM-Code erzeugt, wie können dann auf dieser Ebene die Cuda-Befehle erhalten bleiben? Nvidias NVCC wird immer wieder "Compiler Driver" genannt, die haben dazu auch ein Schemabild: http://docs.nvidia.com/cuda/cuda-compil ... trajectory, was ich aber (noch) nicht wirklich verstehe. Wie muss man sich das vorstellen? Der Hostcompiler übersetzt den C++-Code, bis er eine Cuda-Passage findet. Die übergibt er an nvcc, das erzeugt daraus Code für Kepler/Maxwell/etc. und gibt den Maschienencode dem Hostcompiler zurück, welcher diesen dann als Assembler einbindet? So würde ich das in einem ersten Ansatz machen, aber welche Rolle spielt dabei LLVM?

Ich hoffe, ich kann diese Fragen alle noch vor Abgabe der Arbeit klären.

[mse]

Hmm, sehe ich das richtig, dass man, anstatt den Weg von llvm-Pascal zu gehen und einen neuen Pascal-Parser für den LLVM-Compiler zu schreiben, auch einfach Freepascal, oder deinen MSE-Compiler direkt Code für die LLVM-Architektur erzeugen lassen kann?

MSElang funktioniert so:
Die Sprach-Syntax/Parser-Struktur wird in einer Textdatei definiert (mselang/grammar.gra). Das Tool mselang/grammargen erzeugt daraus die entsprechende Daten- und Steuerstrukturen als kompilierbare Pascal unit. Der universelle MSElang Compiler kompiliert den Quelltext anhand dieser definitions-unit in einen stack-machine basierten Zwischencode. Dieser Code ist von mselang/runtime/mlr direkt ausführbar. Der Zweck ist hauptsächlich der Test des MSElang frontends und die Einbindung einfacher scripts in kompilierte Programme.
In einem weiteren Schritt werden die Befehle des Zwischencodes in LLVM Bitcode (bc) umgewandelt. Diese bc-Datei wird dem LLVM Optimierer und Compiler zur Erzeugung des ausführbaren Programms übergeben.

Die soll ja so ähnlich sein, wie ARM. Wenn ich das richtig verstanden habe, wäre das dann ein normales Cross-Compiling, von x86-Windows nach LLVM. Und von da aus dann später wieder nach x86-Windows, was aber LLVM erledigen würde. Weil dann bräuchte man sich wegen Multi-Compilereinbindung oder Debugger keine Gedanken machen.

Das verstehe ich nicht so ganz. Die RTL muss auf jeden Fall auf das Zielsystem angepasst werden, auch um die verschiedene ABI's muss man sich auf der Frontendseite kümmern. Die debugger Information muss zum Bitcode als Metadata hinzugefügt werden, LLVM produziert dann DWARF Segmente in den Objektdateien welche hoffentlich vom Debugger verstanden werden.

Gibt es für LLVM-Programme auch so eine Art Runtime, bevor diese in x86 oder was auch immer übersetzt werden? Das stelle ich mir schwierig vor, wenn das Programm auf Windows-API oder ähnliches zugreift...

Ja, lli. Arbeitet als Interpreter oder just-in-time Compiler. Ob man damit externe kompilierte Bibliotheken verwenden kann weiss ich nicht.

[mschnell]

Ja, lli. Arbeitet als Interpreter oder just-in-time Compiler.

Bedeutet das, dass LLVM ähnlich wie Java (aka dalvik)) oder CIL (aka .NET, aka C#) einen Architektur-unabkängigen Byte-Code zum distribuieren der "executables" verwendet (oder verwenden kann), der dann auf dem Zielsystem alternativ real-time interpretiert, just-in-time vorkompiliert oder auch vor der Ausführung komplett zu nativen Executable-Dateien kompiliert und werden kann?

-Michael

[mse]

Ja, JIT ist nicht auf allen Plattformen implementiert.

[marcov]

Bedeutet das, dass LLVM ähnlich wie Java (aka dalvik)) oder CIL (aka .NET, aka C#) einen Architektur-unabkängigen Byte-Code zum distribuieren der "executables" verwendet (oder verwenden kann), der dann auf dem Zielsystem alternativ real-time interpretiert, just-in-time vorkompiliert oder auch vor der Ausführung komplett zu nativen Executable-Dateien kompiliert und werden kann?

Nein. Primär gab es das nur für Kommunikation zwischen die verschiebende Teilen (Front, mittel und Backend) von LLVM, ähnlich zur IR von GCC (ab gcc 3 glaube ich. Hieß früher Gimple).

Front sind meistens parsing+semantics. Mittel end sind Optimizationen auf IR Niveau, Backend ist nativer Code Generation.

Den letzte paar Jahr haben jedoch samt GCC und LLVM an JIT Lösungen gearbeitet, und die kommen in zb GCC 5.0 und der folgenden LLVM Version. Das ist aber nicht Teil von eine normalen LLVM Nutzung, das ist alles C++ und statisch Kompiliert.

[mse]

http://llvm.org/docs/CommandGuide/lli.html