Bahasa yang Dikompilasi vs. Diartikan


284

Saya mencoba untuk mendapatkan pemahaman yang lebih baik tentang perbedaannya. Saya telah menemukan banyak penjelasan online, tetapi mereka cenderung ke arah perbedaan abstrak daripada implikasi praktis.

Sebagian besar pengalaman pemrograman saya dengan CPython (dinamis, ditafsirkan), dan Java (statis, dikompilasi). Namun, saya mengerti bahwa ada jenis lain dari bahasa yang ditafsirkan dan dikompilasi. Terlepas dari kenyataan bahwa file yang dapat dieksekusi dapat didistribusikan dari program yang ditulis dalam bahasa yang dikompilasi, apakah ada kelebihan / kekurangan untuk setiap jenis? Seringkali, saya mendengar orang berpendapat bahwa bahasa yang ditafsirkan dapat digunakan secara interaktif, tetapi saya percaya bahwa bahasa yang dikompilasi dapat memiliki implementasi interaktif juga, benar?


32
Anda memilih bahasa yang paling buruk untuk perbandingan ini. Keduanya bytecompiled. Satu-satunya perbedaan nyata di antara mereka adalah JITer, dan bahkan Python memiliki sebagian (psyco).
Ignacio Vazquez-Abrams

1
Contoh bagus dari bahasa kompilasi interaktif adalah Clojure - semuanya dikompilasi sepenuhnya (pertama ke JVM kemudian ke kode asli melalui JIT). Namun banyak kompilasi terjadi secara dinamis, dan pengembangan sering dilakukan dalam shell REPL interaktif di mana Anda dapat mengevaluasi fungsi apa pun yang Anda inginkan di lingkungan yang berjalan.
mikera

Standar ML adalah bahasa kompilasi interaktif lainnya; kompiler bawaan mengeluarkan kode mesin asli asli juga.
Donal Fellows


Jawaban:


459

Bahasa yang dikompilasi adalah bahasa tempat program, setelah dikompilasi, diekspresikan dalam instruksi mesin target. Misalnya, operasi "+" tambahan dalam kode sumber Anda dapat diterjemahkan langsung ke instruksi "ADD" dalam kode mesin.

Bahasa ditafsirkan adalah salah satu di mana petunjuk tidak langsung dieksekusi oleh mesin target, melainkan membaca dan dieksekusi oleh program lain (yang biasanya adalah ditulis dalam bahasa mesin asli). Misalnya, operasi "+" yang sama akan dikenali oleh interpreter pada saat run time, yang kemudian akan memanggil fungsi "add (a, b)" sendiri dengan argumen yang sesuai, yang kemudian akan menjalankan kode mesin "ADD" instruksi .

Anda dapat melakukan apa saja yang dapat Anda lakukan dalam bahasa yang ditafsirkan dalam bahasa yang dikompilasi dan sebaliknya - keduanya Turing lengkap. Namun keduanya memiliki kelebihan dan kekurangan untuk implementasi dan penggunaan.

Saya akan benar-benar menggeneralisasi (purists memaafkan saya!) Tetapi, secara kasar, inilah kelebihan dari bahasa yang dikompilasi:

  • Kinerja lebih cepat dengan langsung menggunakan kode asli mesin target
  • Peluang untuk menerapkan optimisasi yang cukup kuat selama tahap kompilasi

Dan inilah kelebihan dari bahasa yang ditafsirkan:

  • Lebih mudah diimplementasikan (menulis kompiler yang baik sangat sulit !!)
  • Tidak perlu menjalankan tahap kompilasi: dapat menjalankan kode secara langsung "on the fly"
  • Dapat lebih nyaman untuk bahasa dinamis

Perhatikan bahwa teknik modern seperti kompilasi bytecode menambah kompleksitas tambahan - yang terjadi di sini adalah bahwa kompiler menargetkan "mesin virtual" yang tidak sama dengan perangkat keras yang mendasarinya. Instruksi mesin virtual ini kemudian dapat dikompilasi lagi pada tahap selanjutnya untuk mendapatkan kode asli (mis. Seperti yang dilakukan oleh kompiler Java JVM JIT).


1
Tidak semua bahasa yang dikompilasi membutuhkan tahap kompilasi yang lambat. Implementasi Common Lisp yang serius adalah kompiler, dan mereka sering tidak peduli dengan penerjemah, lebih suka mengkompilasi dengan cepat. Di sisi lain, Java memang membutuhkan langkah kompilasi, dan biasanya terlihat.
David Thornley

2
@ Karareem: kompiler JIT hanya melakukan 1) dan 2) sekali - setelah itu adalah kode asli sepanjang jalan. Penerjemah perlu melakukan keduanya 1) dan 2) setiap kali kode dipanggil (yang mungkin banyak, berkali-kali ...). Jadi seiring waktu, kompiler JIT menang dengan selisih yang panjang.
mikera

3
Ya bytecode diterjemahkan ke kode mesin di beberapa titik selama eksekusi program secara keseluruhan (yang bertentangan dengan sebelum eksekusi program, seperti halnya dengan kompiler tradisional). Tetapi sepotong kode tertentu dapat dieksekusi 10 juta kali selama eksekusi program secara keseluruhan. Itu (mungkin) hanya dapat dikompilasi sekali dari bytecode ke kode mesin. Oleh karena itu overhead runtime JIT kecil, dan dapat diabaikan untuk program yang sudah berjalan lama. Setelah kompiler JIT selesai melakukan tugasnya, Anda akan secara efektif menjalankan kode mesin murni sepenuhnya.
mikera

2
Ini sebenarnya dikotomi palsu. Tidak ada yang intrinsik pada bahasa yang membuatnya mengkompilasi interpretasi kami. Ini tidak lebih dari kesalahpahaman yang dipegang secara luas. Banyak bahasa memiliki implementasi dan semua bahasa dapat memiliki keduanya.
mmachenry

2
@mmachenry itu bukan dikotomi palsu. "bahasa pemrograman" mencakup desain dan implementasi. Sementara dalam pengertian teoritis definisi bahasa yang diberikan dapat dikompilasi dan diinterpretasikan, dalam praktik dunia nyata ada banyak perbedaan dalam implementasi. Belum ada yang memecahkan cara mengkompilasi konstruksi bahasa tertentu secara efektif, misalnya - ini adalah masalah penelitian terbuka.
mikera

99

Bahasa itu sendiri tidak dikompilasi atau diinterpretasikan, hanya implementasi spesifik dari suatu bahasa. Java adalah contoh sempurna. Ada platform berbasis bytecode (JVM), kompiler asli (gcj) dan interpeter untuk superset Java (bsh). Jadi, apa itu Java sekarang? Kompilasi bytecode, kompilasi asli atau ditafsirkan?

Bahasa lain, yang disusun serta ditafsirkan, adalah Scala, Haskell atau Ocaml. Masing-masing bahasa ini memiliki juru bahasa interaktif, serta kompiler ke kode byte atau kode mesin asli.

Jadi, secara umum mengkategorikan bahasa dengan "dikompilasi" dan "ditafsirkan" tidak masuk akal.


3
Saya setuju. Atau katakanlah: Ada kompiler asli (membuat kode mesin untuk dimakan CPU), dan kompiler yang tidak asli (membuat hal-hal yang diberi tokenized, yaitu kode perantara, yang dikompilasi oleh beberapa kompiler just-in-time ke kode mesin sebelumnya ( atau selama) runtime ONCE), dan ada non-kompiler "nyata" yang tidak pernah menghasilkan kode mesin dan tidak pernah membiarkan CPU menjalankan kode. Yang terakhir adalah penerjemah. Saat ini, kompiler asli yang secara langsung menghasilkan kode mesin (CPU) pada waktu kompilasi menjadi semakin langka. Delphi / Codegear adalah salah satu penyintas terbaik.
TheBlastOne

57

Mulailah berpikir dalam bentuk: ledakan dari masa lalu

Dahulu kala, dahulu kala, hiduplah di negeri penterjemah dan kompiler komputasi. Segala macam keributan terjadi karena kelebihan satu sama lain. Pendapat umum pada waktu itu adalah sesuatu di sepanjang garis:

  • Juru Bahasa: Cepat untuk mengembangkan (mengedit dan menjalankan). Lambat untuk dieksekusi karena setiap pernyataan harus ditafsirkan ke dalam kode mesin setiap kali dieksekusi (pikirkan apa artinya ini untuk sebuah loop yang dieksekusi ribuan kali).
  • Kompiler: Lambat untuk berkembang (edit, kompilasi, tautkan dan jalankan. Langkah-langkah kompilasi / tautan bisa membutuhkan waktu yang serius). Cepat dieksekusi. Seluruh program sudah dalam kode mesin asli.

Satu atau dua urutan perbedaan besarnya dalam kinerja runtime ada antara program yang ditafsirkan dan program yang dikompilasi. Poin pembeda lain, runability time-run dari kode misalnya, juga menarik, tetapi perbedaan utama berkisar pada masalah kinerja run-time.

Saat ini bentang alam telah berkembang sedemikian rupa sehingga perbedaan yang dikompilasi / ditafsirkan cukup tidak relevan. Banyak bahasa yang dikompilasi memanggil layanan run-time yang tidak sepenuhnya berdasarkan kode mesin. Juga, sebagian besar bahasa yang ditafsirkan "dikompilasi" ke dalam byte-code sebelum dieksekusi. Interpreter kode byte bisa sangat efisien dan menyaingi beberapa kompiler yang dihasilkan kode dari sudut pandang kecepatan eksekusi.

Perbedaan klasiknya adalah bahwa kompiler menghasilkan kode mesin asli, interpreter membaca kode sumber dan membuat kode mesin dengan cepat menggunakan semacam sistem run-time. Saat ini ada sangat sedikit penafsir klasik yang tersisa - hampir semua dari mereka mengkompilasi ke dalam byte-code (atau keadaan semi-dikompilasi lainnya) yang kemudian berjalan pada "mesin" virtual.


1
Bagus - ringkasan bagus di paragraf terakhir - terima kasih!
ckib16

26

Kasus-kasus ekstrim dan sederhana:

  • Kompiler akan menghasilkan biner yang dapat dieksekusi dalam format asli yang dapat dieksekusi mesin target. File biner ini berisi semua sumber daya yang diperlukan kecuali perpustakaan sistem; ini siap dijalankan tanpa persiapan dan pemrosesan lebih lanjut dan berjalan seperti kilat karena kode tersebut adalah kode asli untuk CPU pada mesin target.

  • Seorang juru bahasa akan memberikan perintah kepada pengguna dalam satu lingkaran di mana ia dapat memasukkan pernyataan atau kode, dan pada saat memukul RUNatau yang setara, juru bahasa akan memeriksa, memindai, menguraikan, dan mengeksekusi secara interpretatif setiap baris sampai program berjalan ke titik penghentian atau kesalahan. . Karena setiap baris diperlakukan sendiri dan penerjemah tidak "mempelajari" apa pun dari melihat baris sebelumnya, upaya mengubah bahasa yang dapat dibaca manusia menjadi instruksi mesin dilakukan setiap waktu untuk setiap baris, jadi ini lambat. Sisi baiknya, pengguna dapat memeriksa dan berinteraksi dengan programnya dengan berbagai cara: Mengubah variabel, mengubah kode, menjalankan dalam mode jejak atau debug ... apa pun.

Dengan semua itu, izinkan saya menjelaskan bahwa hidup tidak sesederhana itu lagi. Misalnya,

  • Banyak penerjemah akan melakukan pra-kompilasi kode yang diberikan sehingga langkah penerjemahan tidak harus diulangi lagi dan lagi.
  • Beberapa kompiler mengkompilasi bukan untuk instruksi mesin khusus CPU tetapi untuk bytecode, semacam kode mesin buatan untuk mesin fiktif. Ini membuat program yang dikompilasi sedikit lebih portabel, tetapi membutuhkan juru kode bytecode pada setiap sistem target.
  • The bytecode interpreter (Saya sedang melihat Java di sini) baru-baru ini cenderung mengkompilasi ulang bytecode yang mereka dapatkan untuk CPU dari bagian target sesaat sebelum eksekusi (disebut JIT). Untuk menghemat waktu, ini sering hanya dilakukan untuk kode yang sering berjalan (hotspot).
  • Beberapa sistem yang terlihat dan bertindak seperti penerjemah (Clojure, misalnya) mengkompilasi kode apa pun yang mereka dapatkan, segera, tetapi memungkinkan akses interaktif ke lingkungan program. Itu pada dasarnya kenyamanan penerjemah dengan kecepatan kompilasi biner.
  • Beberapa kompiler tidak benar-benar mengkompilasi, mereka hanya pra-intisari dan kompres kode. Saya mendengar beberapa waktu yang lalu bagaimana cara kerja Perl. Jadi kadang-kadang kompiler hanya melakukan sedikit pekerjaan dan sebagian besar masih interpretasi.

Pada akhirnya, hari-hari ini, menafsirkan vs kompilasi adalah trade-off, dengan waktu yang dihabiskan (sekali) kompilasi sering dihargai oleh kinerja runtime yang lebih baik, tetapi lingkungan interpretatif memberikan lebih banyak peluang untuk interaksi. Mengkompilasi vs menafsirkan sebagian besar masalah bagaimana pekerjaan "memahami" program ini dibagi antara proses yang berbeda, dan garis ini agak kabur saat ini karena bahasa dan produk mencoba menawarkan yang terbaik dari kedua dunia.


23

Dari http://www.quora.com/Apa-adalah- perbedaan- antara antara- compiled-and- interpreted- programming- languages

Tidak ada perbedaan, karena "bahasa pemrograman yang dikompilasi" dan "bahasa pemrograman yang ditafsirkan" bukanlah konsep yang bermakna. Bahasa pemrograman apa pun, dan saya benar-benar berarti apa pun, dapat ditafsirkan atau dikompilasi. Dengan demikian, interpretasi dan kompilasi adalah teknik implementasi, bukan atribut bahasa.

Interpretasi adalah teknik di mana program lain, penerjemah, melakukan operasi atas nama program yang ditafsirkan untuk menjalankannya. Jika Anda dapat membayangkan membaca sebuah program dan melakukan apa yang dikatakannya selangkah demi selangkah, katakan pada selembar kertas awal, itulah yang dilakukan oleh seorang juru bahasa juga. Alasan umum untuk menginterpretasikan suatu program adalah karena juru bahasa relatif mudah untuk menulis. Alasan lain adalah bahwa seorang juru bahasa dapat memantau apa yang coba dilakukan suatu program saat dijalankan, untuk menegakkan kebijakan, katakanlah, untuk keamanan.

Kompilasi adalah teknik di mana program yang ditulis dalam satu bahasa ("bahasa sumber") diterjemahkan ke dalam program dalam bahasa lain ("bahasa objek"), yang semoga berarti sama dengan program aslinya. Saat melakukan terjemahan, biasanya kompiler juga mencoba mengubah program dengan cara yang akan membuat program objek lebih cepat (tanpa mengubah artinya!). Alasan umum untuk mengkompilasi program adalah bahwa ada beberapa cara yang baik untuk menjalankan program dalam bahasa objek dengan cepat dan tanpa overhead untuk menafsirkan bahasa sumber di sepanjang jalan.

Anda mungkin menduga, berdasarkan definisi di atas, bahwa kedua teknik implementasi ini tidak saling eksklusif, dan bahkan mungkin saling melengkapi. Secara tradisional, bahasa objek kompiler adalah kode mesin atau sesuatu yang serupa, yang mengacu pada sejumlah bahasa pemrograman yang dipahami oleh CPU komputer tertentu. Kode mesin kemudian akan dijalankan "pada logam" (meskipun orang mungkin melihat, jika seseorang melihat cukup dekat, bahwa "logam" bekerja sangat mirip penerjemah). Namun, hari ini, sangat umum untuk menggunakan kompiler untuk menghasilkan kode objek yang dimaksudkan untuk ditafsirkan — misalnya, ini adalah bagaimana Java digunakan untuk (dan kadang-kadang masih) bekerja. Ada kompiler yang menerjemahkan bahasa lain ke JavaScript, yang kemudian sering dijalankan di browser web, yang mungkin menafsirkan JavaScript, atau kompilasi mesin virtual atau kode asli. Kami juga memiliki juru bahasa untuk kode mesin, yang dapat digunakan untuk meniru satu jenis perangkat keras pada perangkat lainnya. Atau, seseorang dapat menggunakan kompiler untuk menghasilkan kode objek yang kemudian menjadi kode sumber untuk kompiler lain, yang mungkin bahkan mengkompilasi kode dalam memori tepat pada waktunya untuk dijalankan, yang pada gilirannya. . . Anda mendapatkan idenya. Ada banyak cara untuk menggabungkan konsep-konsep ini.


Dapatkah Anda memperbaiki kalimat ini: "Ada kompiler yang menerjemahkan bahasa lain ke JavaScript, yang kemudian sering dijalankan di browser web, yang mungkin menafsirkan JavaScript, atau mengkompilasinya dengan mesin virtual atau kode asli."
Koray Tugay

Berhasil. Kesalahan umum lainnya adalah mengaitkan kegunaan bahasa dengan API yang ada.
Little Endian

10

Keuntungan terbesar dari kode sumber yang ditafsirkan dibandingkan kode sumber yang dikompilasi adalah PORTABILITAS .

Jika kode sumber Anda dikompilasi, Anda perlu mengkompilasi executable yang berbeda untuk setiap jenis prosesor dan / atau platform yang Anda inginkan untuk menjalankan program Anda (misalnya satu untuk Windows x86, satu untuk Windows x64, satu untuk Linux x64, dan sebagainya di). Selain itu, kecuali jika kode Anda sepenuhnya memenuhi standar dan tidak menggunakan fungsi / pustaka platform-spesifik, Anda benar-benar harus menulis dan memelihara beberapa basis kode!

Jika kode sumber Anda ditafsirkan, Anda hanya perlu menulisnya sekali dan dapat ditafsirkan dan dieksekusi oleh penerjemah yang sesuai pada platform apa pun! Ini portabel ! Perhatikan bahwa seorang penerjemah itu sendiri adalah sebuah program executable yang sudah ditulis dan disusun untuk platform tertentu.

Keuntungan dari kode yang dikompilasi adalah menyembunyikan kode sumber dari pengguna akhir (yang mungkin merupakan kekayaan intelektual ) karena alih-alih menggunakan kode sumber asli yang dapat dibaca manusia, Anda menggunakan file biner yang dapat dieksekusi yang tidak jelas.


1
pada istilah ini java tidak dapat dianggap sebagai "bahasa dikompilasi", tetapi fase kompilasi memberikan keuntungan kompilasi (pengecekan tipe, deteksi kesalahan dini, dll.), dan menghasilkan bytecode yang dapat dijalankan pada setiap OS, dengan Java mesin virtual disediakan.
Rogelio Triviño

7

Compiler dan interpreter melakukan pekerjaan yang sama: menerjemahkan bahasa pemrograman ke bahasa pgoramming lain, biasanya lebih dekat ke perangkat keras, seringkali kode mesin langsung dapat dieksekusi.

Secara tradisional, "dikompilasi" berarti bahwa terjemahan ini terjadi semua dalam satu waktu, dilakukan oleh pengembang, dan dieksekusi yang dihasilkan didistribusikan kepada pengguna. Contoh murni: C ++. Kompilasi biasanya memakan waktu yang cukup lama dan mencoba melakukan banyak optmisasi mahal sehingga eksekusi yang dihasilkan dapat berjalan lebih cepat. Pengguna akhir tidak memiliki alat dan pengetahuan untuk mengkompilasi barang-barang sendiri, dan yang dapat dieksekusi sering harus dijalankan pada berbagai perangkat keras, sehingga Anda tidak dapat melakukan banyak optimasi perangkat keras khusus. Selama pengembangan, langkah kompilasi terpisah berarti siklus umpan balik yang lebih panjang.

Secara tradisional, "ditafsirkan" berarti bahwa terjemahan terjadi "dengan cepat", ketika pengguna ingin menjalankan program. Contoh murni: vanilla PHP. Penerjemah yang naif harus mengurai dan menerjemahkan setiap bagian kode setiap kali dijalankan, yang membuatnya sangat lambat. Tidak dapat melakukan optimasi yang rumit dan mahal karena membutuhkan waktu lebih lama daripada waktu yang dihemat dalam eksekusi. Tetapi sepenuhnya dapat menggunakan kemampuan perangkat keras yang dijalankannya. Kurangnya langkah kompilasi terpisah mengurangi waktu umpan balik selama pengembangan.

Tapi saat ini "dikompilasi vs. ditafsirkan" bukan masalah hitam-putih, ada nuansa di antaranya. Naif, penerjemah sederhana sudah hampir punah. Banyak bahasa menggunakan proses dua langkah di mana kode tingkat tinggi diterjemahkan ke bytecode platform-independent (yang jauh lebih cepat untuk ditafsirkan). Kemudian Anda memiliki "kompilator tepat waktu" yang mengkompilasi kode paling banyak sekali per program dijalankan, kadang-kadang hasil cache, dan bahkan secara cerdas memutuskan untuk menafsirkan kode yang jarang berjalan, dan melakukan optimasi kuat untuk kode yang banyak berjalan. Selama pengembangan, debugger mampu mengalihkan kode di dalam program yang sedang berjalan bahkan untuk bahasa yang dikompilasi secara tradisional.


1
Namun, model kompilasi C ++ diwarisi dari C dan dirancang tanpa mempertimbangkan fitur seperti templat. Kecanggungan ini berkontribusi pada waktu kompilasi C ++ yang lama jauh lebih banyak daripada faktor lainnya - dan menjadikannya contoh yang buruk.

4

Pertama, klarifikasi, Java tidak sepenuhnya dikompilasi statis dan terhubung dengan cara C ++. Ia dikompilasi menjadi bytecode, yang kemudian ditafsirkan oleh JVM. JVM dapat pergi dan melakukan kompilasi just-in-time ke bahasa mesin asli, tetapi tidak harus melakukannya.

Lebih tepatnya: saya pikir interaktivitas adalah perbedaan praktis utama. Karena semuanya ditafsirkan, Anda dapat mengambil kutipan kecil dari kode, parsing dan jalankan melawan kondisi lingkungan saat ini. Jadi, jika Anda sudah mengeksekusi kode yang menginisialisasi variabel, Anda akan memiliki akses ke variabel itu, dll. Itu benar-benar cocok untuk hal-hal seperti gaya fungsional.

Akan tetapi, penafsiran membutuhkan banyak biaya, terutama ketika Anda memiliki sistem besar dengan banyak referensi dan konteks. Menurut definisi, ini boros karena kode identik mungkin harus ditafsirkan dan dioptimalkan dua kali (walaupun sebagian besar runtimes memiliki beberapa caching dan optimisasi untuk itu). Namun, Anda membayar biaya runtime dan seringkali membutuhkan lingkungan runtime. Anda juga cenderung melihat optimasi antar-prosedur yang kompleks karena saat ini kinerjanya tidak cukup interaktif.

Oleh karena itu, untuk sistem besar yang tidak akan banyak berubah, dan untuk bahasa tertentu, lebih masuk akal untuk mengkompilasi dan prelink semuanya, lakukan semua optimasi yang dapat Anda lakukan. Ini berakhir dengan runtime yang sangat ramping yang sudah dioptimalkan untuk mesin target.

Sedangkan untuk menghasilkan executbles, itu tidak ada hubungannya dengan itu, IMHO. Anda sering dapat membuat executable dari bahasa yang dikompilasi. Tetapi Anda juga dapat membuat executable dari bahasa yang ditafsirkan, kecuali bahwa interpreter dan runtime sudah dikemas dalam exectuable dan disembunyikan dari Anda. Ini berarti bahwa Anda umumnya masih membayar biaya runtime (walaupun saya yakin bahwa untuk beberapa bahasa ada cara untuk menerjemahkan semuanya ke pohon yang dapat dieksekusi).

Saya tidak setuju bahwa semua bahasa dapat dibuat interaktif. Bahasa tertentu, seperti C, sangat terikat pada mesin dan seluruh struktur tautan sehingga saya tidak yakin Anda dapat membangun versi interaktif yang lengkap dan bermakna


C tidak benar-benar terikat pada "mesin". Sintaks dan semantik C agak sederhana. Seharusnya tidak terlalu sulit untuk mengimplementasikan C-interpreter, hanya sangat memakan waktu (karena perpustakaan standar harus diimplementasikan juga). Dan btw, Java dapat dikompilasi menjadi kode mesin asli (menggunakan gcj).
lunaryorn

@Lunaryorn: Saya tidak setuju tentang GCJ. GCJ hanya memberi Anda lingkungan berbasis eksekusi. "Aplikasi yang dikompilasi ditautkan dengan runtime GCJ, libgcj, yang menyediakan perpustakaan kelas inti, pengumpul sampah, dan penerjemah bytecode"
Uri

2
GCJ memang menghasilkan kode mesin asli, dan bukan hanya lingkungan yang dapat dieksekusi dengan interpreter dan bytecode tertanam. libgcj menyediakan interpreter bytecode untuk mendukung panggilan dari kode asli ke bytecode Java, bukan untuk menafsirkan program yang dikompilasi. Jika libgcj tidak menyediakan interpreter bytecode, GCJ tidak akan memenuhi spesifikasi Java.
lunaryorn

@Lunaryorn: Ah. Ok, saya menghargai klarifikasi dan diperbaiki. Kami terutama menggunakan Java di lingkungan windows jadi saya belum pernah mencoba gcj selama bertahun-tahun.
Uri


2

Agak sulit untuk memberikan jawaban praktis karena perbedaannya adalah tentang definisi bahasa itu sendiri. Dimungkinkan untuk membangun penerjemah untuk setiap bahasa yang dikompilasi, tetapi tidak mungkin untuk membangun kompiler untuk setiap bahasa yang ditafsirkan. Ini sangat banyak tentang definisi formal bahasa. Sehingga informatika teoritis menyukai hal-hal yang tidak disukai di universitas.


1
Tentunya Anda dapat membangun kompiler untuk bahasa yang ditafsirkan, tetapi kode mesin yang dikompilasi itu sendiri adalah cermin dari runtime.
Aiden Bell

2

The Python Book © 2015 Imagine Publishing Ltd, cukup menghilangkan perbedaan dengan petunjuk berikut yang disebutkan di halaman 10 sebagai:

Bahasa yang ditafsirkan seperti Python adalah bahasa tempat kode sumber dikonversi ke kode mesin dan kemudian dieksekusi setiap kali program dijalankan. Ini berbeda dari bahasa yang dikompilasi seperti C, di mana kode sumber hanya dikonversi ke kode mesin sekali - kode mesin yang dihasilkan kemudian dieksekusi setiap kali program berjalan.


1

Kompilasi adalah proses membuat program yang dapat dieksekusi dari kode yang ditulis dalam bahasa pemrograman yang dikompilasi. Kompilasi memungkinkan komputer untuk menjalankan dan memahami program tanpa perlu perangkat lunak pemrograman yang digunakan untuk membuatnya. Ketika suatu program dikompilasi, ia sering dikompilasi untuk platform tertentu (misalnya platform IBM) yang bekerja dengan komputer yang kompatibel dengan IBM, tetapi tidak untuk platform lain (misalnya platform Apple). Kompiler pertama dikembangkan oleh Grace Hopper saat bekerja pada komputer Harvard Mark I. Saat ini, sebagian besar bahasa tingkat tinggi akan menyertakan kompiler mereka sendiri atau memiliki toolkit yang tersedia yang dapat digunakan untuk mengkompilasi program. Contoh kompiler yang digunakan dengan Java adalah Eclipse dan contoh kompiler yang digunakan dengan C dan C ++ adalah perintah gcc.


0

Definisi pendek (tidak tepat):

Bahasa yang dikompilasi: Seluruh program diterjemahkan ke kode mesin sekaligus, kemudian kode mesin dijalankan oleh CPU.

Bahasa yang ditafsirkan: Program dibaca baris demi baris dan segera setelah baris dibaca instruksi mesin untuk baris tersebut dijalankan oleh CPU.

Tetapi sungguh, beberapa bahasa dewasa ini dikompilasi atau ditafsirkan secara murni, sering kali merupakan campuran. Untuk deskripsi yang lebih rinci dengan gambar, lihat utas ini:

Apa perbedaan kompilasi dan interpretasi?

Atau posting blog saya nanti:

https://orangejuiceliberationfront.com/the-difference-between-compiler-and-interpreter/

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.