Kreuzkompilierung vs Virtual Machines

Question

Klärung

Als ich Kreuz erwähnen Kompilieren ich von einer Sprache in eine andere bedeuten (man denke GWT), anstatt von einer Host-Plattform auf eine Zielplattform.

Hintergrund

ich eine arabische Programmiersprache entwickle, die ich Java kompiliert Kreuz, gespeichert diese mir die plattformspezifische Probleme. Jetzt musste ich das in die Warteschleife setzen und aus verschiedenen Gründen zum Quercompilieren auf C setzen.

Ich möchte eine einzelne Bibliothek entwickeln, die beim Kompilieren durch eine äquivalente Bibliothek des Systems ersetzt wird, auf dem sie ausgeführt wird. Wenn der Programmierer beispielsweise eine GUI-Zeichenfunktion in die arabische Programmiersprache schreibt und kompiliert, würde er unter WinCode kompiliert werden, wenn er unter Windows kompiliert wird, GTK + unter Gnome, Qt unter KDE usw. Derselbe Ansatz wird auch verwendet auch für andere Bibliotheken verwendet werden.

Frage

Lohnt es sich durch all diese Schwierigkeiten gehen mit einem kompilierten ausführbaren am Ende oder bin ich mit einem virtuellen Maschine Ansatz besser? Vor- und Nachteile der Kommissionierung (aus der Perspektive des Sprachentwicklers und nicht des Programmierers, der die Sprache verwendet)? Gibt es noch andere Faktoren, die ich berücksichtigen muss?

würde Jegliche Bezug Links zur weiteren Lektüre sehr zu schätzen :)

Answer 1

Sie sollten auf die Sprache Kreuz kompilieren, die die Annahmen und Ideen zugrunde liegende Sprache am besten unterstützt. Wenn Ihre Sprache "Garbage Collected" ist, sind alle Funktionsaufrufe Methodenaufrufe und Sie können nicht mit Adressen als Daten arbeiten, dann ist Java die Sprache, zu der kompiliert werden soll.

Es gibt Compiler, die Java-Code zu nativen kompilieren. Wenn Sie also Ihr Programm nativ ausführen möchten, können Sie diese verwenden.

Wenn Sie bereit sind, Ihren eigenen vollständigen Compiler für Ihre Sprache zu erstellen, dann können Sie sich von Java oder was auch immer Sie wählen, trennen.

Dieser grundlegende Ansatz wurde von einer Reihe von Sprachen verwendet. Normalerweise ist die Zielsprache C, weil man in C Low-Level-Sachen schreiben kann, die man in keiner anderen Sprache machen kann, es hat ausgereifte Optimierungs-Compiler und läuft nativ sehr schnell. Die Art und Weise, wie die Symbole, Bibliotheken und Aufrufkonventionen von C funktionieren, ist ebenfalls gut verstanden und wird tendenziell streng definiert und von mehreren Sprachen auf jeder gegebenen Plattform unterstützt. Dies ermöglicht der neuen Sprache sofortigen Zugriff auf eine ganze Reihe von Bibliotheken, die für C geschrieben sind. Der ursprüngliche Compiler hieß cfront, und ich glaube, dass OCaml auch auf diese Weise gestartet wurde. Ich denke, wenn Sie ein wenig graben, können Sie zahlreiche andere Sprachen finden, für die das wahr ist.

Wenn Sie jedoch keine Low-Level-Funktionen von Cs benötigen, gelten viele dieser Argumente auch für Java. Einige neuere Sprachen (zB Scala) verwenden die JVM auf diese Weise.

Answer 2

Ich mag @Omnifarious Antwort, aber ich würde stattdessen betonen, dass Sie überlegen müssen, welche Kompromisse Sie machen möchten.Wenn Sie hohe Leistung wünschen, können Sie wählen, ob Sie C oder C++ kompilieren möchten. Wenn Sie die Verfügbarkeit von Bibliotheken wünschen, ist C oder C++ eine gute Wahl. Wenn Sie eine sprachliche Interoperabilität wünschen, können Sie mit LLVM Assembler oder JVM oder .NET Assembler arbeiten.

So, jetzt ist Ihre eigentliche Frage: sollten Sie das Back-End Pluggable machen? Ich muss Sie warnen, dass dies wirklich ist wirklichwirklich schwer zu tun. Schauen wir uns einige Produkte an, die es tatsächlich tun: Das Beispiel ist natürlich gcc. Es unterstützt nicht nur eine Vielzahl von Eingabesprachen, sondern generiert auch Code für eine große Anzahl von Ziel-CPUs: Sie können davon ausgehen, dass es sich um einen Cross-Compiler handelt, der verschiedene Assembler-Sprachen generiert. Das Geheimnis, um das Backend steckbar zu machen, ist eine geeignete Zwischensprache, die einfach genug ist, um Ihre Eingabesprache zu übersetzen, und einfach genug, um in verschiedene Backend-Sprachen zu übersetzen, aber stark genug, um die Eingabe zu kodieren.

Grundsätzlich ist das Problem: Wenn Sie Ihr IL zu abstrakt machen, sperrt es zu viele Ihrer Annahmen kann nicht leicht geändert werden. Wenn Sie es zu konkret machen, ist es zu schwierig, in mehrere Backends zu übersetzen.

Also ich denke, Sie sollten dies tun, wenn, und nur wenn, Sie mindestens drei mögliche Back-End-Zielsprachen als Anwendungsfälle als Leitfaden für Ihr Design der IL haben.