Ist es möglich, einen Port von einer C ++ - Anwendung über LLVM nach Java zu erstellen?

Wie sinnvoll ist es, eine C ++ - Anwendung mithilfe von LLVM (ich denke LLJVM) auf Java-Bytecode zu portieren?

Die Sache ist, dass wir derzeit einen Prozess in C ++ geschrieben haben, aber ein neuer Client hat vorgeschrieben, dass das Programm plattformübergreifend ausgeführt werden kann, wobei die Java Virtual Machine ohne nativen Code (ohne JNI) verwendet wird. Die Idee ist, in der Lage zu sein, das generierte JAR zu nehmen und es dann auf verschiedene Systeme (Linux, Win, 32 Bit - 64 Bit) zu kopieren, und es sollte einfach funktionieren.

Wenn Sie sich umschauen, ist es möglich, C ++ in LLVM-IR-Code und dann diesen Code in Java-Bytecode zu kompilieren. Der generierte Code muss nicht lesbar sein.

Ich habe ein bisschen mit ähnlichen Dingen mit emscripten getestet, dies nimmt C ++ - Code und kompiliert ihn zu JavaScript. Das Ergebnis ist gültiges JS, aber völlig unlesbar (sieht aus wie Assambler).

Hat jemand mit dieser Technik einen Port einer Anwendung von C ++ auf Java-Bytecode erstellt?
Vor welchen Problemen könnten wir stehen?
Ist ein gültiger Ansatz für Produktionscode?

Um meinen Standpunkt nach einigen Kommentaren klarer zu machen: Vielleicht wird der Port nicht gut genutzt. Ich erwarte daher keinen lesbaren Quellcode, sondern nur Java-Bytecode. Es handelt sich also nicht mehr um einen 'Port', für den der Port entwickelt wird Zielplattform muss die Java-JVM sein, nicht der native Assamblear.

Hinweis: Mir ist bekannt, dass wir derzeit einige nicht standardmäßige C ++ - und Close Source-Bibliotheken haben. Wir möchten diesen nicht standardmäßigen Code und alle Close Source-Bibliotheken entfernen und die Open Source-Software Free Libre verwenden. Nehmen wir also an, der gesamte Code ist Standard-C ++ - Code mit Der gesamte Code ist zur Kompilierungszeit verfügbar.

Hinweis 2: Es ist keine Option, portablen C ++ - Code zu schreiben und ihn dann auf die gewünschte Zielplattform zu kompilieren. Das kompilierte Programm muss plattformübergreifend sein, daher die Verwendung von JVM.

Anmerkung 3: Im Moment untersuchen wir keine ähnlichen Lösungen für Python oder andere Sprachgrundlagen, aber ich würde auch gerne davon hören. Damit meine ich, dass unsere ausführbare Zieldatei Java-Bytecode sein muss, aber wenn es Optionen zum Kompilieren von C ++ zu gültigem Python-kompiliertem Code gibt, würde ich auch gerne davon hören.

java c++ porting

— Javier Mr.
quelle

Ich bin mir nicht sicher, was Sie im letzten Satz über Python meinen, aber Jython ist genau das gleiche: Verwenden Sie JVM anstelle der Python-VM und genau in diesem Szenario: Programmierer möchten Python verwenden, die Bereitstellung muss auf JVM erfolgen.

— Javier

Über wie viele Codezeilen sprechen wir? Es mag Ihre Zeit wert sein, es neu zu schreiben, aber das ist keine einfache Entscheidung. Wenn Ihr Code eine Zeigerarithmetik ausführt, wäre ich gespannt, wie dies bei der Arbeit an der JVM gehandhabt wird.

— Levi Morrison

Debuggen, das Spaß machen sollte O_o

— Daniel Gratzer

@ LeviMorrison. Nun, der Code ist ziemlich umfangreich (verschiedene Bibliotheksabhängigkeiten für Kommunikation, Utlity-Funktionen), aber es wird davon ausgegangen, dass wir den gesamten Code zur Kompilierungszeit zur Verfügung haben. Und auch wenn ein anderer Client dies nicht benötigt, generieren wir trotzdem die native Binärdatei.

— Javier Mr

@jozefg. Über Zeigeraritmetik und Debugging erwarte ich kein Debugging. Emscripten macht zum Beispiel dasselbe, aber die Zielsprache ist Javascript. Sie enden nur mit einem großen Byte-Array als Heap- und bitweise Operationen für den Programmzähler und nur Operationen mit Bytes, keine Objekte, Zeichenfolgen oder ähnliches. Ich erwarte, dass das Ergebnis ähnlich wie assamblear im Java-Bytecode ist und nicht als debuggbar angesehen werden kann.

— Javier Mr

Ich bezweifle wirklich, dass dies funktionieren wird. Möglicherweise können Sie Ihren Code in Java-Bytecode übersetzen, aber Bibliotheksaufrufe werden nicht auf magische Weise in entsprechende Aufrufe der Java-Laufzeit und der Bibliotheken übersetzt. Möglicherweise gibt es nicht einmal gleichwertige Java-Laufzeitaufrufe! Selbst wenn Sie alle proprietären Bibliotheken entfernen, bleibt Ihnen die C ++ - Standardbibliothek erhalten.

Um dies konkret zu machen: Ihr C ++ - Programm enthält möglicherweise einen Aufruf von fprintf (). Diese Funktion ist in der C-Standardbibliothek implementiert und für ein C ++ - Programm absolut legitim. Der LLVM-zu-LLJVM-Übersetzer wird wahrscheinlich nicht auf magische Weise die Reihenfolge der Java-Laufzeitaufrufe herausfinden, die das zu fprintf () äquivalente Ergebnis liefern, und diese ersetzen. Um diese Funktion bereitzustellen, müsste die C- und C ++ - Laufzeit in Java im Wesentlichen neu implementiert werden Bytecode.

Es gibt einige Tools , die eine Übersetzung von C ++ nach Java durchführen, aber nur eine Handvoll der einfacheren Aufrufe der Laufzeitbibliothek konvertieren. Der Rest bleibt Ihnen überlassen, um herauszufinden.

— Charles E. Grant
quelle

Ich verstehe Ihren Standpunkt, aber soweit ich weiß, macht emscripten etwas Ähnliches mit dem Ziel Javascript, wenn ich nicht missverstanden habe, dass emscripten eine benutzerdefinierte Standardbibliothek bereitstellt, um zu vermeiden, worauf Sie hingewiesen haben (und sogar Zuordnungen für webGL durch SDL-Bibliothek) ). Aber ich kann das Äquivalent für Java nicht finden (LLJVM scheint aufgegeben zu sein). Ich denke darüber nach, llvm-Bytecode als plattformunabhängigen Build vorzuschlagen (natürlich ohne Kompilierungszweige, abhängig von der Plattform, nach API oder Daten; unter Verwendung aproder ähnlichem)

— Javier Mr

lljvm bietet eine C-Laufzeitbibliothek, teilweise als C, kompiliert in JVM-Bytecode, und teilweise als Java-Klassen. Es ist eine ziemlich vollständige Bibliothek. Sie müssten das Äquivalent für libstdc ++ erstellen. Auch das lljvm-Backend unterstützt C ++ momentan sowieso nicht. Ich habe versucht, lljvm zu reparieren, um mit einem neueren llvm-Build zu arbeiten. Es geht nur langsam voran, da sich die llvm-APIs und -Tools zwischen den Releases ständig ändern. Sie können hier mitlesen, es ist jetzt fast in brauchbarer Form. github.com/hyc/lljvm/tree/llvm3.3

— hyc