Apakah layak untuk membuat port dari aplikasi C ++ ke Java melalui LLVM


9

seberapa layak untuk mem-port aplikasi C ++ ke Java bytecode menggunakan LLVM (saya kira LLJVM)?

Masalahnya adalah bahwa saat ini kami memiliki proses yang ditulis dalam C ++ tetapi klien baru telah membuat wajib untuk dapat menjalankan program dengan cara multiplatform, menggunakan Java Virtual Machine dengan jelas tanpa kode asli (tanpa JNI). Idenya adalah untuk dapat mengambil toples yang dihasilkan dan menyalin kemudian ke sistem yang berbeda (Linux, Win, 32 bit - 64 bit) dan seharusnya berfungsi.

Melihat sekeliling tampak seperti mungkin untuk mengkompilasi kode C ++ ke LLVM IR dan kemudian kode itu ke bytecode java. Kode yang dihasilkan tidak perlu dibaca.

Saya telah menguji sedikit dengan hal-hal serupa menggunakan emscripten, ini membutuhkan kode C ++ dan kompilasi ke JavaScript. Hasilnya adalah JS yang valid tetapi benar-benar tidak dapat dibaca (seperti assambler).

  • Adakah yang melakukan port aplikasi dari C ++ ke Java bytecode menggunakan teknik ini?
  • Masalah apa yang bisa kita hadapi?
  • Apakah pendekatan yang valid untuk kode produksi?

Untuk memperjelas poin saya setelah beberapa komentar, mungkin port tidak digunakan dengan baik, saya tidak mengharapkan kode sumber yang dapat dibaca sebagai hasilnya, hanya java bytecode, jadi itu bukan 'port' yang akan dikembangkan lagi, hanya saja target plattform harus java JVM bukan assamblear asli.

Catatan: Saya sadar bahwa saat ini kami memiliki beberapa pustaka sumber C + + dan non-standar, kami sedang mencari untuk menghapus kode non-pangkalan ini dan semua pustaka sumber dekat dan menggunakan Free Libre Open Source Software, jadi anggaplah semua kode adalah kode standar C ++ dengan semua kode tersedia pada waktu kompilasi.

Note2: Ini bukan pilihan untuk menulis kode C ++ portabel dan kemudian mengkompilasinya ke platform target yang diinginkan, program yang dikompilasi harus multiplatform, sehingga penggunaan JVM.

Note3: Saat ini kami tidak mencari solusi serupa yang diterapkan pada Python atau basis bahasa lain, tetapi saya juga ingin mendengarnya. Dengan ini saya maksudkan bahwa target kita yang dapat dieksekusi harus bytecode java tetapi jika ada opsi untuk mengkompilasi C ++ ke kode terkompilasi python yang valid saya juga ingin mendengar tentang mereka.


tidak yakin apa yang Anda maksud pada kalimat terakhir tentang Python, tetapi Jython persis sama: gunakan JVM dan bukan Python VM, dan digunakan dalam skenario itu: programmer ingin menggunakan Python, penyebaran harus di JVM.
Javier

Berapa banyak baris kode yang kita bicarakan? Mungkin perlu waktu Anda untuk menulis ulang, tetapi itu bukan keputusan sederhana. Juga, jika kode Anda melakukan aritmatika pointer apa pun, saya akan penasaran untuk mengetahui bagaimana hal itu ditangani ketika bekerja pada JVM.
Levi Morrison

1
Debugging yang seharusnya menyenangkan O_o
Daniel Gratzer

@LeviMorrison. Yah kodenya cukup luas (berbagai dependensi pustaka untuk komunikasi, fungsi utlity) tetapi diasumsikan bahwa kami telah menyediakan semua kode pada waktu kompilasi. Dan juga jika klien lain tidak membutuhkannya, kami masih akan menghasilkan biner asli.
Javier,

@ jozefg. Tentang pointer aritmetics dan debugging bertujuan agar saya tidak berharap dapat debuggable. Emscripten misalnya melakukan hal yang sama tetapi bahasa targetnya adalah Javascript, Anda berakhir hanya dengan array byte besar sebagai operasi heap dan bit wise untuk penghitung program dan hanya operasi dengan byte tanpa objek, string atau hal seperti itu. Saya mengharapkan hasil yang mirip dengan assamblear di bytecode java, bisa diasumsikan tidak dapat debuggable.
Javier,

Jawaban:


11

Saya benar-benar ragu ini akan berhasil. Anda mungkin dapat menerjemahkan kode Anda ke kode byte Java, tetapi itu tidak akan secara ajaib menerjemahkan panggilan perpustakaan menjadi panggilan yang setara dengan Java runtime dan libraries. Bahkan mungkin tidak ada panggilan Java runtime yang setara! Bahkan jika Anda menghilangkan semua perpustakaan eksklusif Anda masih tersisa dengan perpustakaan standar C ++.

Untuk membuat ini konkret: program C ++ Anda mungkin berisi panggilan ke fprintf (). Fungsi itu diimplementasikan dalam pustaka standar C dan sangat sah untuk memanggil program C ++. Penerjemah LLVM ke LLJVM mungkin tidak akan secara ajaib mengetahui urutan panggilan run time Java yang akan menghasilkan hasil yang setara dengan fprintf () dan menggantikan mereka yang masuk. Untuk menyediakan fasilitas tersebut pada dasarnya akan memerlukan implementasi ulang runtime C dan C ++ di Jawa kode byte

Ada beberapa alat yang melakukan terjemahan C ++ ke Java tetapi mereka hanya mengkonversi beberapa panggilan pustaka runtime yang lebih sederhana. Sisanya diserahkan kepada Anda untuk mencari tahu.


Saya mengerti maksud Anda, tetapi sejauh yang saya mengerti emscripten melakukan sesuatu yang mirip dengan target menjadi Javascript, jika saya tidak salah paham emscripten menyediakan perpustakaan standar khusus untuk menghindari apa yang Anda tunjukkan (dan bahkan pemetaan untuk webGL melalui perpustakaan SDL) ). Tetapi saya tidak dapat menemukan yang setara untuk Java (LLJVM tampaknya ditinggalkan). Saya berpikir untuk mengusulkan byvecode llvm sebagai platform yang independen (tentu saja tanpa cabang kompilasi tergantung pada platform, dengan API atau data; menggunakan apratau serupa)
Javier Mr

3
lljvm menyediakan pustaka runtime C, sebagian sebagai C dikompilasi ke bytecode JVM, dan sebagian lagi sebagai kelas Java. Ini adalah libc yang cukup lengkap. Anda perlu membuat yang setara untuk libstdc ++. Juga backend lljvm sebenarnya tidak mendukung C ++ saat ini. Saya sudah mencoba untuk memperbaiki lljvm agar berfungsi dengan build llvm yang lebih baru. Ini berjalan lambat karena API dan alat llvm terus berubah begitu banyak di antara rilis. Anda dapat mengikuti di sini, itu hampir dalam kondisi yang dapat digunakan sekarang. github.com/hyc/lljvm/tree/llvm3.3
hyc
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.