Mengapa tidak memiliki OS berbasis Bahasa Tingkat Tinggi? Apakah Bahasa Tingkat Rendah lebih efisien?


44

Tanpa sombong, saya ingin Anda mempertimbangkan kemungkinan ini. Sebagian besar OS saat ini didasarkan pada bahasa tingkat rendah (terutama C / C ++). Bahkan yang baru seperti Android menggunakan JNI & implementasi yang mendasarinya adalah dalam bahasa C

Bahkan, (ini adalah pengamatan pribadi) banyak program yang ditulis dalam C berjalan jauh lebih cepat daripada rekan-rekan tingkat tinggi mereka (misalnya: Transmisi (klien bittorrent di Ubuntu) jauh lebih cepat daripada Vuze (Java) atau Deluge (Python) ). Bahkan kompiler python ditulis dalam C, meskipun PyPy adalah pengecualian.

Jadi, apakah ada alasan khusus untuk ini? Mengapa semua yang kita sebut "Bahasa Tingkat Tinggi" dengan konsep "OOP" yang hebat tidak dapat digunakan dalam membuat OS yang solid?

Jadi saya punya 2 pertanyaan pada dasarnya.

  1. Mengapa aplikasi yang ditulis dalam bahasa tingkat rendah lebih efisien daripada rekan-rekan HLL mereka? Apakah bahasa tingkat rendah berkinerja lebih baik karena alasan sederhana bahwa bahasa tingkat rendah dan diterjemahkan ke kode mesin lebih mudah?
  2. Mengapa kita tidak memiliki OS lengkap sepenuhnya berdasarkan sepenuhnya pada Bahasa Level Tinggi?

36
Anda menyiratkan bahwa hanya "Bahasa Level Tinggi" yang berorientasi objek, yang tidak benar.
Uooo

2
@ artindru "Bahasa tingkat rendah yang cukup" (terutama C / C ++)? Apa definisi Anda tentang Bahasa Tingkat Tinggi? Anda harus jelas tentang definisi / interpretasi Bahasa Tingkat Tinggi Anda. Python sebenarnya adalah bahasa scripting karena dieksekusi langsung di mesinnya (IDLE atau terminal baris perintah), jika Anda tidak menyadarinya sekarang. Ada alasan yang sangat bagus (filosofis dan praktis) mengapa C / C ++ digunakan sebagai bahasa implementasi untuk banyak OS, tapi saya yakin pengguna daya di sini mungkin tidak akan melompat ke itu untuk pertanyaan ini.
hagubear

10
Android bukan OS baru. Ini hanyalah rasa Linux.
Den

3
@ hagubear Ada alasan yang sangat bagus (filosofis dan praktis) mengapa C / C ++ digunakan sebagai bahasa implementasi untuk banyak OS . Apa alasan yang sangat bagus ini?
rtindru

2
Jika saya mengerti dengan benar, OS untuk mesin LISP ditulis dalam LISP. Meskipun mungkin bisa dikatakan bahwa dialek yang digunakan adalah bahasa tingkat rendah?
Robert Fisher

Jawaban:


38

Microsoft telah melakukan beberapa penelitian yang sangat menarik dalam arah ini, jika Anda melihat ke Singularitas:

http://research.microsoft.com/en-us/projects/singularity/

Juga, Mothy Roscoe dkk telah bekerja pada Barrelfish yang menggunakan bahasa pemrograman kendala Eclipse sebagai layanan OS untuk memilah semua jenis manajemen OS dan masalah alokasi sumber daya:

http://www.barrelfish.org/


Wow, saya tidak bisa memilih, butuh 15 repetisi ... baru bergabung hari ini! Terima kasih banyak.
rtindru

9
@rtindru: bahkan dengan 1 titik rep Anda dapat menerima jawaban Apa artinya ketika jawaban "diterima"?
Marjan Venema

6
Menerima jawaban cenderung mengurangi jawaban / diskusi baru. Secara pribadi, saya akan merekomendasikan untuk tidak menerima (untuk pertanyaan khusus ini) untuk setidaknya satu hari lagi.
Brian

1
Saya akan menambahkan Cosmos ke kumpulan: open source, pihak ketiga, tidak semenarik singularitas tetapi punya beberapa ide bagus! cosmos.codeplex.com
Lorenzo Dematté

38

Banyak tergantung pada di mana Anda menempatkan pembagian antara bahasa tingkat rendah dan tingkat tinggi. Sebagai contoh, orang yang berbeda cenderung menempatkan bahasa seperti C ++ pada sisi yang berbeda dari pembagian itu.

Mengenai pertanyaan Anda:

  1. Saya tidak percaya ada perbedaan antara bahasa tingkat rendah dan tingkat tinggi, tetapi lebih banyak perbedaan antara bahasa yang ditafsirkan dan bahasa yang dikompilasi dengan instruksi asli.

    Tetapi mungkin juga ada perbedaan budaya antara programmer, di mana sekali yang menggunakan bahasa tingkat rendah lebih fokus pada aspek kinerja dari pilihan (desain) yang mereka buat.

  2. Jika Anda menganggap C ++ sebagai level tinggi, maka setidaknya ada satu OS yang sepenuhnya ditulis dalam bahasa tingkat tinggi (Symbian OS ditulis dalam C ++). Apa yang membuat Anda berhenti menulis OS dalam sebagian besar bahasa tingkat tinggi adalah dua hal:

    • OS membutuhkan akses tingkat rendah ke memori dan perangkat keras dan melakukan trik kotor pada mereka. Jenis akses ini umumnya dianggap tidak aman untuk program tingkat aplikasi, sehingga banyak bahasa tingkat tinggi tidak mengizinkannya.
    • OS perlu dijalankan tanpa perangkat lunak pendukung hadir, seperti juru bahasa. Ini membuatnya sangat sulit untuk menulis OS dalam bahasa yang tidak dapat dengan mudah dikompilasi menjadi instruksi asli.

35
Tidak ada bahasa interpretasi atau bahasa yang mengkompilasi instruksi asli. Sebuah bahasa adalah seperangkat aturan matematika, itu tidak ditafsirkan atau dikompilasi, itu hanya merupakan . Interp. dan Comp. adalah ciri-ciri dari, baik, penerjemah atau kompiler, bukan bahasa. Setiap bahasa dapat diimplementasikan menggunakan kompiler atau juru bahasa. Sebagian besar bahasa sekarang memiliki implementasi yang ditafsirkan dan dikompilasi. Ada penerjemah untuk C dan semua implementasi JavaScript utama mengkompilasi ke kode asli. Dan apa itu kode asli? Jika saya mengkompilasi bytecode dan menjalankan Java ke JVM
Jörg W Mittag

11
bahwa pada Java CPU, dan saya mengkompilasi kode mesin C ke ARM dan menjalankannya pada interpreter ARM karena PC saya tidak memiliki CPU ARM, lalu apa yang membuat ARM asli dan JVML tidak?
Jörg W Mittag

5
@ JörgWMittag: Jika Anda memiliki CPU yang dapat langsung menjalankan bytecode Java (tanpa menggunakan JVM tambahan), maka bytecode Java adalah kode asli untuk CPU tersebut. Juga, saya tidak mengesampingkan kemungkinan menulis OS dalam bahasa yang biasanya ditafsirkan atau dieksekusi dalam VM, tetapi itu membuat mereka pilihan yang kurang jelas.
Bart van Ingen Schenau

15
@ JörgWMittag - Saya setuju bahwa bahasa apa pun dapat dikompilasi atau ditafsirkan (kompilasi skrip bash; gunakan penerjemahan C ++ (CINT / Cling)), tetapi banyak keputusan dalam desain bahasa didasarkan pada apakah ini akan ditafsirkan, dikompilasi, atau keduanya. Bahasa yang membuat Anda secara manual mendeklarasikan / menginisialisasi variabel yang diketik secara statis, mengalokasikan / membebaskan memori secara manual, melakukan aritmatika penunjuk, ingat untuk memeriksa batas array akan kurang nyaman dalam juru bahasa (dibandingkan bahasa yang mengumpulkan sampah memori, menyimpulkan tipe dinamis, memeriksa batas array). Apakah baris ini 100% jelas? Tidak, tetapi ada perbedaan dalam praktiknya.
dr jimbob

15

Ada sejumlah alasan bagus untuk ini.

Bahasa tingkat rendah hari ini adalah bahasa tingkat tinggi kemarin

Ya, percaya atau tidak, pada suatu waktu bahkan C dipandang sebagai bahasa tingkat tinggi. Bahkan ~ 20 tahun yang lalu cukup umum untuk melihatnya digambarkan sebagai bahasa "tingkat menengah". Ini adalah waktu sebelum OO sepopuler sekarang, Java tidak ada, C # tidak ada, bahkan C ++ belum distandarisasi dengan baik.

Kelembaman historis

Sistem operasi yang Anda gunakan saat ini memiliki akar yang dalam dalam sejarah. Windows kembali ke awal / pertengahan 80-an, Unix kembali ke awal / pertengahan 70-an. Ada BANYAK kode lama yang berfungsi dalam sistem operasi, dan Anda umumnya tidak ingin menulis ulang kode yang lama dan berfungsi.

Pada titik tertentu Anda harus pergi ke perangkat keras

Ini terjadi di kernel, itu terjadi di driver, itu terjadi di subsistem manajemen memori, itu terjadi di sistem file. Tentu Anda dapat melapisi bahasa tingkat tinggi di atasnya, tetapi Anda masih membutuhkan kemampuan untuk lebih langsung mengakses perangkat keras yang ditawarkan oleh bahasa tingkat rendah.

Portabilitas

Saya tidak bermaksud portabilitas ke perangkat keras yang berbeda atau OS yang berbeda karena lebih umum dipahami hari ini; ini lebih halus. Ada satu keuntungan utama dari menyediakan antarmuka berbasis C untuk sesuatu, dan itu adalah fakta bahwa hampir setiap bahasa lain yang ada dapat terhubung ke C. Bahkan Windows API masih merupakan API berbasis C saat ini karena alasan itu.

Pilihan pribadi

Beberapa orang lebih suka memprogram dengan cara ini, dan itu bisa menjadi faktor utama. Sebagai contoh, Linus Torvalds memiliki kata-kata kasar yang terkenal terhadap C ++ yang membuatnya cukup jelas bahwa sejauh yang ia ketahui, C akan selalu menjadi alat pilihannya untuk jenis pekerjaan ini (isi kata-kata kasar dan apakah Anda setuju atau tidak dengan itu. tidak relevan dengan diskusi ini; fakta bahwa kata-kata kasar itu ada sudah cukup).

Secara bersama-sama, ini harus secara jelas menetapkan mengapa sistem operasi awalnya ditulis dalam sesuatu seperti C di masa lalu, dan mengapa potongan yang sangat signifikan - bahkan hari ini - tetap demikian.


13

Alasan utama dominasi C untuk sistem operasi terletak pada sejarah - sistem operasi arus utama seperti Windows dan semua bentuk Unix (BSD, Solaris, HP-UX, MacOS X, ... serta klon seperti Linux) kembali lama sekali, sebelum OO dan konstruksi "tingkat tinggi" lainnya menjadi arus utama.

Untuk inti dari sistem operasi selain kinerja ada kebutuhan untuk sangat spesifik tentang instruksi perangkat keras dan satu kebutuhan kontrol penuh atas memori yang bahasa seperti C melakukannya dengan sangat baik.

Untuk embedded system terkadang ada sistem operasi yang menggunakan bahasa level yang lebih tinggi untuk bagian sistem yang lebih besar. Salah satu contoh penting adalah JavaOS oleh Sun.

Untuk sistem operasi yang tersebar luas, contoh penting yang tidak menggunakan C juga adalah MacOS klasik sebelum MacOS X - yang sebagian besar ditulis dalam dialek Pascal yang memungkinkan beberapa bentuk orientasi objek.


12

Pertama, ada beberapa masalah bootstrap. Sebagian besar fitur yang membuat bahasa tingkat tinggi lebih mudah didasarkan pada abstraksi yang harus disediakan sendiri oleh kernel. Bagaimana Anda menulis manajer memori dalam bahasa yang memerlukan manajer memori? Bagaimana Anda menulis driver I / O tanpa menggunakan pustaka I / O standar bahasa Anda yang bagus? Bagaimana Anda membuat primitif threading dan sinkronisasi tanpa menggunakan perpustakaan bahasa?

Kedua, ini sangat berguna dan jauh lebih mudah dibaca ketika menulis sistem operasi untuk dapat menetapkan variabel ke lokasi memori tertentu. Ini mudah di C, dan setiap programmer C tunggal tahu bagaimana melakukannya. Jika bahkan mungkin dalam bahasa tingkat tinggi, sangat jarang bahwa hanya guru yang tahu bagaimana melakukannya.

Dengan kata lain, ketika Anda memperhitungkan semua batasan dan modifikasi yang harus Anda terima, C dan C ++ mulai tampak jauh lebih mudah.


2
Paragraf pertama Anda tidak masuk akal. Driver I / O di C tidak menggunakan stdio.hkeduanya. Implementasi mutex khusus tidak menggunakan pthreads. Itulah tepatnya artinya mengimplementasikannya sendiri! Dan itu tidak tergantung pada bahasa yang Anda gunakan. Itu tidak berarti bahasa tingkat tinggi adalah pilihan yang baik untuk tugas tingkat rendah (biasanya tidak dalam pengalaman saya).

Saya sadar akan hal itu. Saya hanya menunjukkan bahwa banyak hal yang membedakan tingkat tinggi dari bahasa tingkat rendah adalah di bagian-bagian bahasa yang tidak tersedia dalam pengembangan kernel. Ketika Anda membandingkan bahasa inti ke inti, C tidak terlihat begitu sederhana.
Karl Bielefeldt

Tidak sepenuhnya benar. Meskipun Anda memerlukan beberapa kode yang tidak menggunakan X untuk mengimplementasikan X, semua kode yang tersisa dapat bergantung pada kode itu dan menggunakan X.

Itu poin yang bagus.
Karl Bielefeldt

6

Pertama-tama, bootstrap membutuhkan setidaknya sebagian kecil untuk ditulis dalam Majelis atau setara.

Kedua, ada adalah OS ditulis dalam disangkal HLL - Lisp Machine . (Fakta bahwa kegagalan secara komersial lebih terkait dengan perangkat keras lain menjadi lebih cepat lebih murah dan kemenangan Worse lebih baik daripada dengan kekurangan filosofi atau desainnya).

Ketiga, C ++ cukup berorientasi objek dan tingkat tinggi, jadi, seperti yang ditunjukkan orang lain, OS Symbian adalah contoh lain.

Keempat, ada sedikit kebutuhan untuk OS baru saat ini. Kami sudah memiliki beberapa rasa linux dan bsd yang berjalan di hampir semua perangkat keras, dan membuat OS baru dari awal cukup mahal.


Anda melewatkan mainframe Burroughs B5000. Sistem operasi mereka ditulis dalam Burroughs Extended ALGOL.
John R. Strohm

1
there is little need for new OSes at this timeSaya masih belum memutuskan sendiri apakah ini benar atau tidak .. Ya, OS modern (windows modern (NT) / modern Unix) adalah semua yang kita butuhkan, fungsionalitas dan kinerja bijaksana. Tapi nyaris: mereka dilahirkan di daerah lain di mana "bersih" adalah perusahaan / universitas dan pengguna dipercaya, dan multiproc adalah 2/4 prosesor. Mereka "terganggu", sampai taraf tertentu, oleh kepercayaan berlebihan (rootkit, malware, virus ..). Saya mulai berpikir bahwa ada ruang IS untuk OS modern, aman, terisolasi ... dengan dukungan yang lebih baik untuk paralelisme juga (lebih baik daripada utas)
Lorenzo Dematté

Lisp adalah level rendah, CARdan CDRmerupakan macro assembler IBM 704 ! Bahkan C memisahkan perakitan inline , daripada memperlakukannya sebagai fungsi lain. Mengingat Lisp CARdan CDRbekerja pada x86, ARM, dan sejumlah lebih dari ISA, itu adalah beberapa perakitan portabel yang mengesankan. (Catatan untuk siapa pun yang saya mungkin bingung: Ya, Lisp adalah bahasa tingkat tinggi. CARDan CDRmenjadi assembler macro hanyalah detail implementasi, bukan fitur utama.;))
8bittree

4

Untuk fase yang lebih baik apa yang saya tulis sebelumnya.

Mesin Burroughs 5xxx - 6xxx tidak memiliki bahasa rakitan. Bahasa terendah yang tersedia adalah ekstensi ke Algol. Algol diimplementasikan dalam perangkat keras. OS dan semua bahasa ditulis dalam Algol. Itu mengungguli semua mesin pesaing saat itu. Itu juga membutuhkan kode yang jauh lebih sedikit yang membuatnya lebih mudah untuk dipelihara. Itu stack hardware yang mendukung bahasa rekursif seperti Algol.

Sistem operasi Burroughs berevolusi menjadi versi yang disebut MCP. MCP saat ini berjalan pada sistem Unisys.


3

Sebagian besar bahasa tingkat tinggi yang Anda sebutkan memiliki fitur yang tidak cocok dengan sistem operasi: Manajemen memori otomatis. Anda tidak dapat mengandalkan pengumpul sampah saat menulis sistem waktu nyata - baik lunak (yang merupakan sistem operasi) atau bahkan yang paling sulit. Mengutip Tanenbaum [i]:

Beberapa hal yang tidak dimiliki C termasuk string bawaan, utas, paket, kelas, objek, keamanan jenis, dan pengumpulan sampah. Yang terakhir adalah show stopper untuk sistem operasi. Semua penyimpanan dalam C baik statis atau dialokasikan secara eksplisit dan dirilis oleh programmer, biasanya dengan fungsi perpustakaan malloc dan gratis . Ini adalah properti yang terakhir - total kontrol programmer atas memori - bersama dengan pointer eksplisit yang membuat C menarik untuk menulis sistem operasi. Sistem operasi pada dasarnya adalah sistem waktu-nyata sampai batas tertentu, bahkan yang untuk keperluan umum. Ketika interupsi terjadi, sistem operasi mungkin hanya memiliki beberapa mikrodetik untuk melakukan beberapa tindakan atau kehilangan informasi penting. Memiliki pengumpulan sampah menendang pada saat yang sewenang-wenang tidak dapat ditoleransi.

Sekarang, Anda mungkin berpendapat bahwa C ++ juga merupakan kandidat yang baik karena menawarkan manajemen memori manual. C ++ telah digunakan di beberapa sistem operasi seperti Symbian (disebutkan oleh Bart ) dan BeOS. Tetapi IMHO C masih merupakan bahasa tercepat yang dapat porting di banyak arsitektur tanpa usaha besar (berbeda dengan perakitan arsitektur tertentu).

[i]: Sistem Operasi Modern edisi ke-3, halaman 73


3
Mesin simbolik memiliki manajemen memori otomatis. Smalltalk lakukan pada Alto. Itu di tahun 80-an. Sistem tipe linier menghilangkan keharusan untuk GC sepenuhnya. Ini adalah masalah yang diselesaikan, andai saja kita dapat mengingatnya!
Frank Shearar

Mungkin saja bagi suatu bahasa untuk memasukkan manajemen memori otomatis, tetapi menyertakan jenis khusus dari referensi "yang disematkan" dan memungkinkan metode untuk secara eksplisit menyatakan bahwa mereka tidak akan mengakses referensi yang tidak disematkan atau meminta metode apa pun yang mungkin melakukannya. Tidak perlu lagi seorang kolektor sampah dunia untuk mengganggu kode yang berjalan dalam metode yang tidak akan mengakses objek apa pun yang mungkin dimodifikasi oleh GC.
supercat

2

Seperti yang telah ditunjukkan orang lain, beberapa sistem operasi telah ditulis dalam bahasa tingkat tinggi. Mungkin yang Anda maksud adalah bahwa semua OS yang sukses, pasar massal, tujuan umum telah ditulis dalam beberapa kombinasi assembly, C, dan C ++?

Sebagian besar bahasa tingkat tinggi memiliki banyak fitur bermanfaat yang membawa biaya kinerja yang terkait. Manajemen memori otomatis adalah contoh yang jelas, batas memeriksa array adalah hal lain. Jika Anda menulis OS tujuan umum, Anda cenderung mengalami situasi di mana hukuman kinerja dari fitur-fitur bermanfaat ini lebih dari yang Anda bayarkan. Pada titik itu Anda ingin dapat mematikannya. Bahasa-bahasa seperti Python, C #, dan Java bervariasi di mana fitur-fitur yang dapat Anda matikan, tetapi tidak satu pun dari mereka yang serba C atau C ++ dalam hal ini.

Dalam aspek ini C dan C ++ hampir sama serbagunanya dengan perakitan murni. Jika Anda memutuskan bahwa Anda memerlukan sepuluh manajer memori yang berbeda yang mencakup sepuluh skenario alokasi memori yang berbeda, Anda dapat menerapkan semuanya dalam C dan C ++, dan memuat dan membongkar semuanya sesuai keinginan Anda. Heck, Anda bahkan tidak perlu menautkan ke pustaka runtime C standar atau kode startup jika Anda tidak mau.


0

Jawaban sebenarnya adalah Uang . Tidak ada manfaat yang dirasakan cukup dari OS bahasa tingkat tinggi untuk membenarkan pengeluaran sumber daya untuk membangun satu dan kemudian mendorongnya ke arus utama. Misalnya, ada biaya besar untuk membangun driver baru untuk setiap perangkat keras yang perlu didukung.

Ada berbagai OS yang ditulis dalam bahasa tingkat tinggi, dengan tujuan utama penelitian, seperti Oberon dan Singularity .

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.