Apakah yang dapat dieksekusi memerlukan kernel OS untuk dijalankan?

Saya tahu bahwa ketika kode sumber, dalam katakanlah C ++, dikompilasi, output dari kompiler adalah kode mesin (executable) yang saya pikir adalah instruksi ke CPU secara langsung. Baru-baru ini saya membaca kernel dan saya menemukan bahwa program tidak dapat mengakses perangkat keras secara langsung tetapi harus melalui kernel.

Jadi ketika kita mengkompilasi beberapa kode sumber sederhana, katakan hanya dengan printf()fungsi, dan kompilasi menghasilkan kode mesin yang dapat dieksekusi, akankah masing-masing instruksi dalam kode mesin ini dieksekusi langsung dari memori (setelah kode dimuat ke dalam memori oleh OS) atau akan setiap perintah dalam kode mesin masih harus melalui OS (kernel) yang akan dieksekusi?

Saya telah membaca pertanyaan serupa . Itu tidak menjelaskan apakah kode mesin yang dihasilkan setelah kompilasi adalah instruksi untuk CPU secara langsung atau jika perlu kembali melalui kernel untuk membuat instruksi yang benar untuk CPU. Yaitu, apa yang terjadi setelah kode mesin dimuat ke dalam memori? Apakah akan melalui kernel atau langsung berbicara dengan prosesor?

Sebagai seseorang yang memiliki program tertulis yang mengeksekusi tanpa OS, saya menawarkan jawaban yang pasti.

Apakah yang dapat dieksekusi memerlukan kernel OS untuk dijalankan?

Itu tergantung pada bagaimana program itu ditulis dan dibangun.
Anda bisa menulis sebuah program (dengan asumsi Anda memiliki pengetahuan) yang tidak memerlukan OS sama sekali.
Program semacam itu digambarkan sebagai program mandiri .
Boot loader dan program diagnostik adalah kegunaan khas untuk program mandiri.

Namun program khas yang ditulis dan dibangun di beberapa lingkungan OS host akan default untuk mengeksekusi di lingkungan OS host yang sama.
Diperlukan keputusan dan tindakan yang sangat eksplisit untuk menulis dan membangun program mandiri.

... output dari kompiler adalah kode mesin (executable) yang saya pikir adalah instruksi ke CPU secara langsung.

Benar.

Baru-baru ini saya membaca kernel dan saya menemukan bahwa program tidak dapat mengakses perangkat keras secara langsung tetapi harus melalui kernel.

Itu pembatasan yang diberlakukan oleh mode CPU yang digunakan OS untuk menjalankan program, dan difasilitasi oleh alat bantu bangunan tertentu seperti kompiler dan perpustakaan.
Ini bukan batasan intrinsik pada setiap program yang pernah ditulis.

Jadi ketika kita mengkompilasi beberapa kode sumber sederhana, katakan saja dengan fungsi printf (), dan kompilasi menghasilkan kode mesin yang dapat dieksekusi, masing-masing instruksi dalam kode mesin ini akan langsung dieksekusi dari memori (setelah kode dimuat ke dalam memori oleh OS ) atau apakah setiap perintah dalam kode mesin masih harus melalui OS (kernel) yang akan dieksekusi?

Setiap instruksi dijalankan oleh CPU.
Instruksi yang tidak didukung atau ilegal (mis. Proses memiliki hak istimewa tidak mencukupi) akan menyebabkan pengecualian langsung, dan CPU akan menjalankan rutin untuk menangani kondisi yang tidak biasa ini.

Fungsi printf () tidak boleh digunakan sebagai contoh "kode sumber sederhana" .
Terjemahan dari bahasa pemrograman tingkat tinggi berorientasi objek ke kode mesin mungkin tidak sepele seperti yang Anda maksudkan.
Dan kemudian Anda memilih salah satu fungsi paling kompleks dari pustaka runtime yang melakukan konversi data dan I / O.

Perhatikan bahwa pertanyaan Anda menetapkan lingkungan dengan OS (dan pustaka runtime).
Setelah sistem di-boot, dan OS diberikan kendali atas komputer, pembatasan diberlakukan pada apa yang dapat dilakukan suatu program (misalnya I / O harus dilakukan oleh OS).
Jika Anda berharap untuk menjalankan program mandiri (yaitu tanpa OS), maka Anda tidak boleh mem-boot komputer untuk menjalankan OS.

... apa yang terjadi setelah kode mesin dimuat ke dalam memori?

Itu tergantung lingkungan.

Untuk program mandiri, dapat dijalankan, yaitu kontrol diserahkan dengan melompat ke alamat awal program.

Untuk program yang dimuat oleh OS, program harus dihubungkan secara dinamis dengan pustaka bersama yang menjadi tempat bergantungnya. OS harus membuat ruang eksekusi untuk proses yang akan menjalankan program.

Apakah akan melalui kernel atau langsung berbicara dengan prosesor?

Kode mesin dijalankan oleh CPU.
Mereka tidak "pergi melalui kernel" , tetapi mereka juga tidak "berbicara dengan prosesor" .
Kode mesin (terdiri dari kode op dan operan) adalah instruksi untuk CPU yang diterjemahkan dan operasi dilakukan.

Mungkin topik berikutnya yang harus Anda selidiki adalah mode CPU .

Kernel adalah "hanya" lebih banyak kode. Hanya saja kode itu adalah lapisan yang hidup di antara bagian terendah dari sistem Anda dan perangkat keras yang sebenarnya.

Semua itu berjalan langsung pada CPU, Anda hanya transisi melalui lapisan itu untuk melakukan apa saja.

Program Anda "membutuhkan" kernel dengan cara yang sama seperti itu membutuhkan pustaka C standar untuk menggunakan printfperintah di tempat pertama.

Kode sebenarnya dari program Anda berjalan pada CPU, tetapi cabang-cabang yang membuat kode untuk mencetak sesuatu di layar pergi melalui kode untuk printffungsi C , melalui berbagai sistem dan penerjemah lainnya, yang masing-masing melakukan pemrosesan sendiri untuk mengetahui bagaimana hello world! sebenarnya akan dicetak di layar Anda.

Katakanlah Anda memiliki program terminal yang berjalan di desktop window manager, berjalan di kernel Anda yang pada gilirannya berjalan di perangkat keras Anda.

Ada banyak lagi yang terjadi tetapi tetap sederhana ...

1. Dalam program terminal Anda, Anda menjalankan program Anda untuk mencetak hello world!
2. Terminal melihat bahwa program telah menulis (melalui rutin keluaran C) hello world!ke konsol
3. Program terminal naik ke window manager desktop yang mengatakan "aku hello world!menulis pada saya, bisa Anda letakkan di posisi x, yplease?"
4. Desktop window manager naik ke kernel dengan "salah satu program saya ingin perangkat grafis Anda meletakkan teks pada posisi ini, dapatkan itu dude!"
5. Kernel menyampaikan permintaan ke driver perangkat grafis, yang memformatnya sedemikian rupa sehingga kartu grafis dapat mengerti
6. Bergantung pada bagaimana kartu grafis terhubung, driver perangkat kernel lain perlu dipanggil untuk mendorong data keluar pada bus perangkat fisik seperti PCIe, menangani hal-hal seperti memastikan perangkat yang benar dipilih, dan bahwa data dapat melewati jembatan yang relevan atau konverter
7. Perangkat keras menampilkan hal-hal.

_{Ini adalah penyederhanaan besar yang berlebihan hanya untuk deskripsi. Di sini ada naga.}

Secara efektif semua yang Anda lakukan yang memerlukan akses perangkat keras, baik itu tampilan, blok memori, bit file atau apa pun yang harus melalui beberapa driver perangkat di kernel untuk mengetahui cara berbicara dengan perangkat yang relevan. Baik itu driver sistem file di atas driver controller hard disk SATA yang dengan sendirinya berada di atas perangkat PCIe bridge.

Kernel tahu cara mengikat semua perangkat ini bersama-sama dan menyajikan antarmuka yang relatif sederhana bagi program untuk melakukan sesuatu tanpa harus tahu tentang bagaimana melakukan semua hal ini sendiri.

Manajer jendela desktop menyediakan lapisan yang berarti bahwa program tidak harus tahu cara menggambar jendela dan bermain dengan baik dengan program lain yang mencoba menampilkan sesuatu pada saat yang bersamaan.

Akhirnya program terminal berarti bahwa program Anda tidak perlu tahu cara menggambar jendela, atau bagaimana berbicara dengan driver kartu grafis kernel, atau semua kerumitan yang berkaitan dengan berurusan dengan buffer layar dan tampilan waktu dan benar-benar menggoyangkan jalur data ke layar.

Itu semua ditangani oleh lapisan demi lapisan kode.

Itu tergantung pada lingkungan. Dalam banyak komputer lama (dan lebih sederhana!), Seperti IBM 1401, jawabannya adalah "tidak". Kompiler dan tautan Anda mengeluarkan "biner" mandiri yang berjalan tanpa sistem operasi sama sekali. Ketika program Anda berhenti berjalan, Anda memuat yang berbeda, yang juga berjalan tanpa OS.

Sistem operasi diperlukan di lingkungan modern karena Anda tidak menjalankan hanya satu program pada satu waktu. Berbagi inti CPU, RAM, perangkat penyimpanan massal, keyboard, mouse, dan tampilan, di antara beberapa program sekaligus membutuhkan koordinasi. OS menyediakan itu. Jadi dalam lingkungan modern program Anda tidak bisa hanya membaca dan menulis disk atau SSD, ia harus meminta OS untuk melakukan itu atas namanya. OS mendapatkan permintaan seperti itu dari semua program yang ingin mengakses perangkat penyimpanan, mengimplementasikan hal-hal seperti kontrol akses (tidak dapat memungkinkan pengguna biasa menulis ke file OS), mengantre mereka ke perangkat, dan memilah informasi yang dikembalikan ke program yang benar (proses).

Selain itu, komputer modern (tidak seperti, katakanlah, 1401) mendukung koneksi berbagai perangkat I / O yang sangat luas, bukan hanya yang akan dijual IBM kepada Anda di masa lalu. Kompiler dan tautan Anda tidak mungkin mengetahui semua kemungkinan. Misalnya, keyboard Anda mungkin dihubungkan melalui PS / 2, atau USB. OS memungkinkan Anda untuk menginstal "driver perangkat" khusus perangkat yang tahu cara berbicara dengan perangkat tersebut, tetapi menghadirkan antarmuka umum untuk kelas perangkat ke OS. Jadi program Anda, dan bahkan OS, tidak harus melakukan sesuatu yang berbeda untuk mendapatkan penekanan tombol dari USB vs keyboard PS / 2, atau untuk mengakses, katakanlah, disk SATA lokal vs perangkat penyimpanan USB vs penyimpanan yang ada di suatu tempat pada NAS atau SAN. Rincian tersebut ditangani oleh driver perangkat untuk berbagai pengontrol perangkat.

Untuk perangkat penyimpanan massal, OS menyediakan di atas semua itu driver sistem file yang menyajikan antarmuka yang sama ke direktori dan file terlepas dari mana dan bagaimana penyimpanan diimplementasikan. Dan lagi, OS khawatir tentang kontrol akses dan serialisasi. Secara umum, misalnya, file yang sama tidak boleh dibuka untuk ditulis oleh lebih dari satu program sekaligus tanpa melompati beberapa rintangan (tetapi bacaan simultan umumnya ok).

Jadi di lingkungan serba guna modern, ya - Anda benar-benar membutuhkan OS. Tetapi bahkan hari ini ada komputer seperti pengontrol waktu nyata yang tidak cukup rumit untuk membutuhkannya.

Di lingkungan Arduino, misalnya, sebenarnya tidak ada OS. Tentu, ada banyak kode perpustakaan yang menggabungkan lingkungan binaan ke dalam setiap "biner" yang dibangunnya. Tetapi karena tidak ada kegigihan dari kode itu dari satu program ke program berikutnya, itu bukan OS.

Saya pikir banyak jawaban salah memahami pertanyaan, yang bermuara pada ini:

Kompiler menghasilkan kode mesin. Apakah kode mesin ini dieksekusi langsung oleh CPU, atau apakah "ditafsirkan" oleh kernel?

Pada dasarnya, CPU secara langsung mengeksekusi kode mesin . Akan lebih lambat secara signifikan untuk memiliki kernel menjalankan semua aplikasi. Namun, ada beberapa peringatan.

1. Ketika OS hadir, program aplikasi biasanya dilarang menjalankan instruksi tertentu atau mengakses sumber daya tertentu. Misalnya, jika aplikasi menjalankan instruksi yang memodifikasi tabel interupsi sistem, CPU akan langsung beralih ke pengendali pengecualian OS sehingga aplikasi yang melanggar dihentikan. Selain itu, aplikasi biasanya tidak diizinkan untuk membaca / menulis ke memori perangkat. (Yaitu "berbicara dengan perangkat keras".) Mengakses wilayah memori khusus ini adalah bagaimana OS berkomunikasi dengan perangkat seperti kartu grafis, antarmuka jaringan, jam sistem, dll.

2. Batasan yang ditempatkan OS pada aplikasi dicapai oleh fitur-fitur khusus CPU, seperti mode privilege, perlindungan memori, dan interupsi. Meskipun CPU apa pun yang Anda temukan di smartphone atau PC memiliki fitur-fitur ini, CPU tertentu tidak. CPU ini memang membutuhkan kernel khusus yang "menafsirkan" kode aplikasi untuk mencapai fitur yang diinginkan. Contoh yang sangat menarik adalah Gigatron , yang merupakan komputer 8-instruksi yang dapat Anda bangun dari chip yang mengemulasi komputer 34-instruksi.

3. Beberapa bahasa seperti Java "kompilasi" untuk sesuatu yang disebut Bytecode, yang sebenarnya bukan kode mesin. Meskipun di masa lalu mereka diinterpretasikan untuk menjalankan program, hari ini sesuatu yang disebut kompilasi Just-in-Time biasanya digunakan sehingga mereka akhirnya berjalan langsung pada CPU sebagai kode mesin.

4. Menjalankan perangkat lunak dalam Mesin Virtual yang digunakan untuk meminta kode mesinnya untuk "ditafsirkan" oleh program yang disebut Hypervisor . Karena permintaan industri yang sangat besar untuk VM, pabrikan CPU telah menambahkan fitur seperti VTx ke CPU mereka untuk memungkinkan sebagian besar instruksi sistem tamu dijalankan langsung oleh CPU. Namun, ketika menjalankan perangkat lunak yang dirancang untuk CPU yang tidak kompatibel di Mesin Virtual (misalnya, meniru NES), kode mesin perlu ditafsirkan.

Ketika Anda mengkompilasi kode Anda, Anda membuat apa yang disebut kode "objek" yang (dalam banyak kasus) tergantung pada pustaka sistem ( printfmisalnya), kemudian kode Anda dibungkus oleh linker yang akan menambahkan jenis pemuat program yang dapat dilakukan oleh sistem operasi khusus Anda kenali (itulah sebabnya Anda tidak dapat menjalankan program yang dikompilasi untuk Windows di Linux misalnya) dan tahu cara membuka kode Anda dan menjalankannya. Jadi program Anda adalah seperti daging di dalam sandwich dan hanya bisa dimakan sebagai satu bundel.

Baru-baru ini saya membaca kernel dan saya menemukan bahwa program tidak dapat mengakses perangkat keras secara langsung tetapi harus melalui kernel.

Yah itu setengah benar; jika program Anda adalah driver mode kernel maka sebenarnya Anda dapat mengakses perangkat keras secara langsung jika Anda tahu cara "berbicara" dengan perangkat keras, tetapi biasanya (terutama untuk perangkat keras yang tidak terdokumentasi atau rumit) orang menggunakan driver yang merupakan pustaka kernel. Dengan cara ini Anda dapat menemukan fungsi API yang tahu cara berbicara dengan perangkat keras dengan cara yang hampir dapat dibaca manusia tanpa perlu mengetahui alamat, register, waktu dan banyak hal lainnya.

apakah setiap instruksi dalam kode mesin ini akan langsung dieksekusi dari memori (setelah kode dimuat ke dalam memori oleh OS) atau masing-masing setiap perintah dalam kode mesin masih harus melalui OS (kernel) yang akan dieksekusi

Kernel adalah sebagai pelayan, yang tanggung jawabnya adalah memandu Anda ke meja dan melayani Anda. Satu-satunya hal yang tidak dapat dilakukan - itu adalah makan untuk Anda, Anda harus melakukannya sendiri. Sama dengan kode Anda, kernel akan membongkar program Anda ke memori dan akan memulai kode Anda yang merupakan kode mesin yang dieksekusi langsung oleh CPU. Kernel hanya perlu mengawasi Anda - apa yang diizinkan dan apa yang tidak boleh Anda lakukan.

itu tidak menjelaskan apakah kode mesin yang dihasilkan setelah kompilasi adalah instruksi untuk CPU secara langsung atau akankah perlu lagi melalui kernel untuk membuat instruksi yang benar untuk CPU?

Kode mesin yang dihasilkan setelah kompilasi adalah instruksi ke CPU secara langsung. Tidak diragukan lagi. Satu-satunya hal yang perlu Anda ingat, tidak semua kode dalam file yang dikompilasi adalah kode mesin / CPU yang sebenarnya. Linker membungkus program Anda dengan beberapa data meta yang hanya dapat ditafsirkan oleh kernel, sebagai petunjuk - apa yang harus dilakukan dengan program Anda.

Apa yang terjadi setelah kode mesin dimuat ke memori? Apakah akan melalui kernel atau langsung berbicara dengan prosesor.

Jika kode Anda hanya opcode sederhana seperti penambahan dua register maka akan dieksekusi langsung oleh CPU tanpa bantuan kernel, tetapi jika kode Anda menggunakan fungsi dari pustaka maka panggilan tersebut akan dibantu oleh kernel, seperti pada contoh dengan pelayan, jika Anda ingin untuk makan di restoran mereka akan memberi Anda alat - garpu, sendok (dan itu masih aset mereka) tetapi apa yang akan Anda lakukan dengan itu, - hingga "kode" Anda.

Yah, hanya untuk mencegah nyala dalam komentar - ini adalah model yang sangat disederhanakan yang saya harap akan membantu OP memahami hal-hal dasar, tetapi saran yang bagus untuk meningkatkan jawaban ini disambut baik.

Jadi ketika kita mengkompilasi kode sumber sederhana, katakan hanya dengan fungsi printf (), dan kompilasi menghasilkan kode mesin yang dapat dieksekusi, masing-masing instruksi dalam kode mesin ini akan langsung dieksekusi dari memori (setelah kode tersebut dimuat ke dalam memori oleh OS) atau akankah masing-masing setiap perintah dalam kode mesin masih harus melalui OS (kernel) yang akan dieksekusi?

Pada dasarnya, hanya panggilan sistem yang masuk ke kernel. Apa pun yang berkaitan dengan I / O atau alokasi / dealokasi memori pada akhirnya menghasilkan panggilan sistem. Beberapa instruksi hanya dapat dijalankan dalam mode kernel dan akan menyebabkan CPU memicu pengecualian. Pengecualian menyebabkan beralih ke mode kernel dan lompat ke kode kernel.

Kernel tidak memproses setiap instruksi dalam suatu program. Itu hanya panggilan sistem dan beralih antara menjalankan program untuk berbagi CPU.

Melakukan alokasi memori dalam mode pengguna (tanpa kernel) tidak dimungkinkan, jika Anda mengakses memori Anda tidak memiliki izin untuk mengakses, MMU, yang sebelumnya diprogram oleh kernel, pemberitahuan dan menyebabkan pengecualian "segmentasi kesalahan" tingkat CPU. , yang memicu kernel, dan kernel membunuh program.

Melakukan I / O dalam mode pengguna (tanpa kernel) tidak dimungkinkan, jika Anda mengakses port I / O atau mendaftar untuk perangkat, atau alamat yang terhubung ke perangkat (satu atau keduanya diperlukan untuk melakukan I / O), ini memicu pengecualian dengan cara yang sama.

Apakah yang dapat dieksekusi memerlukan kernel OS untuk dijalankan?

Tergantung pada jenis yang dapat dieksekusi.

Kernel, selain memediasi akses bersama ke RAM dan perangkat keras, juga melakukan fungsi loader.

Banyak "format yang dapat dieksekusi", seperti ELF atau PE, memiliki metadata dalam file yang dapat dieksekusi di samping kode, dan tugas pemuatnya untuk memprosesnya. Baca detail berdarah tentang format Microsoft PE untuk informasi lebih lanjut.

File yang dapat dieksekusi ini juga mereferensi pustaka ( file .dllobjek bersama Windows atau Linux .so) - kodenya harus disertakan.

Jika kompiler Anda menghasilkan file yang dimaksudkan untuk diproses oleh loader sistem operasi, dan loader itu tidak ada, itu tidak akan berfungsi.

• Bisakah Anda memasukkan kode yang berfungsi sebagai loader?

Tentu. Anda perlu meyakinkan OS untuk menjalankan kode mentah Anda tanpa memproses metadata apa pun. Jika kode Anda memanggil API kernel, itu masih tidak akan berfungsi.

• Bagaimana jika itu tidak memanggil API kernel?

Jika Anda memuat executable ini entah bagaimana dari sistem operasi entah bagaimana (yaitu jika memungkinkan kode mentah untuk dimuat dan dieksekusi), itu masih akan berada dalam mode pengguna. Jika kode Anda mengakses hal-hal yang dilarang dalam mode pengguna, sebagai lawan dari mode kernel, seperti memori yang tidak dialokasikan atau alamat / register perangkat I / O, kode itu akan macet dengan hak istimewa atau pelanggaran segmen (sekali lagi, pengecualian masuk ke mode kernel dan ditangani di sana) dan masih tidak akan berfungsi.

• Bagaimana jika Anda menjalankannya dari mode kernel.

Maka akan berhasil.

TL; DR No.

Perkembangan Arduino muncul di pikiran sebagai lingkungan saat ini di mana tidak ada OS. Percayalah pada salah satu bayi ini Anda tidak memiliki ruang untuk sistem operasi.

Demikian juga, game untuk Sega Genesis tidak memiliki OS yang disediakan oleh Sega untuk dipanggil. Anda baru saja membuat game Anda di assembler 68K, menulis langsung ke bare metal.

Atau di mana saya memotong gigi, melakukan pekerjaan tertanam pada Intel 8051. Sekali lagi ketika Anda memiliki 2716 eprom dengan jejak 2k * 8, Anda tidak memiliki ruang untuk sistem operasi.

Tentu saja, ini mengasumsikan penggunaan kata aplikasi yang sangat luas. Sebagai pertanyaan retoris, ada baiknya bertanya pada diri sendiri apakah sketsa Arduino sebenarnya adalah aplikasi.

Walaupun saya tidak ingin menyiratkan bahwa jawaban lain tidak benar pada mereka sendiri, mereka memberikan terlalu banyak detail yang, saya khawatir, masih sangat tidak jelas bagi Anda.

Jawaban dasarnya adalah bahwa kode akan dieksekusi langsung pada prosesor. Dan tidak, kode mesin tidak akan "berbicara" kepada siapa pun, itu sebaliknya. Prosesor adalah komponen aktif dan semua yang Anda lakukan di komputer Anda akan dilakukan oleh prosesor itu (saya menyederhanakan beberapa hal di sini tapi tidak apa-apa untuk saat ini). Prosesor akan membaca kode dan menjalankannya dan mengeluarkan hasilnya, kode mesin hanyalah makanan untuk prosesor.

Kebingungan Anda berasal dari penggunaan kata perangkat keras. Meskipun pembagiannya tidak sejelas yang seharusnya, lebih baik jika Anda berpikir dalam hal peripheral daripada hanya memanggil semua perangkat keras. Jadi, jika ada sistem operasi atau yang serupa pada mesin Anda, program Anda harus menggunakan layanannya untuk mengakses periferal tetapi prosesor itu sendiri bukan periferal, itu adalah unit pemrosesan utama yang menjalankan program Anda secara langsung.

Kernel, sistem operasi dan lapisan intervening serupa biasanya hanya digunakan dalam sistem yang lebih besar di mana ada harapan bahwa beberapa program akan berjalan dan ada kebutuhan bagi sistem untuk mengelola bagaimana program ini dapat menggunakan periferal komputer (cukup sering di waktu yang sama). Dalam kasus ini, menjalankan program hanya dapat mengakses periferal ini menggunakan sistem yang akan memutuskan bagaimana membagikannya dan akan memastikan tidak ada konflik. Sistem kecil di mana tidak perlu ada manajemen di antara program yang bersaing karena tidak ada, seringkali tidak memiliki sistem yang mendasari sama sekali dan program tunggal yang biasanya berjalan pada sistem ini lebih atau kurang bebas untuk melakukan apa pun yang diinginkan dengan periferal.

BIOS yang berjalan di komputer saat dihidupkan adalah kode yang dapat dieksekusi yang disimpan dalam ROM. Ini terdiri dari instruksi mesin plus data. Ada kompiler (atau assembler) yang merakit BIOS ini dari kode sumber. Ini adalah kasus khusus.

Kasus khusus lainnya termasuk program bootstrap yang memuat kernel dan kernel itu sendiri. Kasus khusus ini umumnya dikodekan dalam bahasa selain C ++.

Dalam kasus umum, jauh lebih praktis untuk membuat kompiler menghasilkan beberapa instruksi yang memanggil layanan sistem yang disediakan oleh kernel atau oleh rutinitas perpustakaan. Itu membuat kompiler jauh lebih ringan. Ini juga membuat kode yang dikompilasi lebih ringan.

Di ujung lain dari spektrum adalah Jawa. Di Jawa, kompiler tidak menerjemahkan kode sumber ke dalam instruksi mesin, karena istilah ini biasanya dipahami. Sebaliknya, kode sumber diterjemahkan ke dalam "instruksi mesin" untuk mesin imajiner, yang disebut Java Virtual Machine. Sebelum sebuah program Java dapat berjalan, itu harus dikombinasikan dengan Java runtime, yang mencakup seorang juru bahasa untuk Java Virtual Machine.

Di masa lalu yang baik, program Anda bertanggung jawab untuk melakukan semua yang perlu dilakukan selama pelaksanaan program Anda, baik dengan Anda melakukannya sendiri atau dengan menambahkan kode pustaka yang ditulis orang lain ke program Anda. Satu-satunya hal yang berjalan di samping itu di komputer adalah kode untuk dibaca di program yang dikompilasi - jika Anda beruntung. Beberapa komputer harus memasukkan kode melalui sakelar sebelum dapat melakukan lebih banyak (proses "bootstrap" asli), atau bahkan seluruh program Anda masuk dengan cara ini.

Dengan cepat ditemukan bahwa itu bagus untuk memiliki kode yang berjalan mampu memuat dan menjalankan program. Kemudian ditemukan bahwa komputer cukup kuat untuk mendukung menjalankan beberapa program pada saat yang sama dengan memiliki saklar CPU di antara mereka, terutama jika perangkat keras dapat membantu, tetapi dengan tambahan kompleksitas program tidak menginjak kaki masing-masing (misalnya , bagaimana menangani beberapa program yang mencoba mengirim data ke printer sekaligus?).

Semua ini menghasilkan sejumlah besar kode pembantu yang dipindahkan dari masing-masing program ke dalam "sistem operasi", dengan cara standar meminta kode pembantu dari program pengguna.

Dan di sanalah kita hari ini. Program Anda berjalan dengan kecepatan penuh tetapi setiap kali mereka membutuhkan sesuatu yang dikelola oleh sistem operasi, mereka menyebut rutinitas pembantu yang disediakan oleh sistem operasi, dan kode itu tidak diperlukan dan tidak ada dalam program pengguna itu sendiri. Ini termasuk menulis ke layar, menyimpan file, mengakses jaringan, dll.

Microkernels telah ditulis yang menyediakan apa yang dibutuhkan untuk menjalankan program tertentu tanpa sistem operasi penuh. Ini memiliki beberapa keuntungan bagi pengguna berpengalaman sambil memberikan sebagian besar lainnya. Anda mungkin ingin membaca halaman Wikipedia tentang hal itu - https://en.wikipedia.org/wiki/Microkernel - jika Anda ingin tahu lebih banyak.

Saya bereksperimen dengan Microkernel yang mampu menjalankan Java Virtual Machine, tetapi menemukan kemudian bahwa sweet spot untuk itu adalah Docker.

Pada OS desktop biasa, kernel itu sendiri adalah executable. (Windows punya ntoskrnl.exe; Linux punya vmlinux, dll.) Jika Anda membutuhkan kernel agar dapat dijalankan, maka OS-OS itu tidak ada.

Yang Anda perlukan untuk kernel adalah melakukan hal-hal yang dilakukan kernel. Izinkan beberapa executable untuk dijalankan sekaligus, wasit di antara mereka, abstraksi perangkat keras, dll. Sebagian besar program tidak mampu melakukan hal-hal itu dengan kompeten, dan Anda tidak akan menginginkannya bahkan jika mereka bisa. Pada zaman DOS - yang hampir tidak bisa disebut sistem operasi itu sendiri - game sering menggunakan OS sebagai lebih dari sebuah loader, dan langsung mengakses perangkat keras seperti halnya kernel. Tetapi Anda sering harus tahu merek dan model perangkat keras apa yang ada di mesin Anda sebelum Anda membeli game. Banyak permainan hanya mendukung keluarga tertentu kartu video dan kartu suara, dan berjalan sangat buruk pada merek yang bersaing jika mereka bekerja sama sekali. Bahwa'