Menempatkan “You” di dalam CPU

• Ini adalah pengantar untuk proyek belajar pribadi yang berupaya memahami sampai tuntas apa yang sebenarnya terjadi saat menjalankan program di komputer
• Pertanyaan utamanya berlanjut ke apakah program berjalan langsung di CPU, bagaimana system call bekerja, dan bagaimana beberapa program dapat berjalan secara bersamaan
• Di luar kuliah universitas, sulit menemukan materi sistem yang komprehensif, sehingga penulis harus menyaring sendiri materi dengan kualitas beragam dan informasi yang saling bertentangan
• Setelah beberapa minggu riset dan membuat hampir 40 halaman catatan, penulis jadi lebih memahami proses komputer dari awal menyala hingga menjalankan program
• Penulis mengatakan bahkan pembaca yang merasa sudah tahu pun mungkin masih bisa mempelajari hal baru, dan menyarankan untuk membaca bab 3 terlebih dahulu jika tidak punya banyak waktu

---

Titik awal untuk memahami eksekusi program

• Titik awal tulisan ini adalah apa persisnya yang terjadi saat menjalankan program di komputer
• Penulis sudah memiliki sejumlah pengetahuan tingkat rendah, tetapi kesulitan menghubungkan berbagai potongan itu menjadi satu alur
• Pertanyaannya bercabang menjadi tiga
  • Apakah program benar-benar berjalan langsung di CPU
  • Apa itu system call dan bagaimana sebenarnya cara kerjanya
  • Bagaimana beberapa program dapat berjalan secara bersamaan

Proses riset dan urutan membaca

• Karena tidak banyak materi sistem yang komprehensif, penulis harus meneliti sendiri dari berbagai sumber, dan kualitas serta isi tiap materi berbeda-beda
• Melalui riset selama beberapa minggu dan hampir 40 halaman catatan, penulis jadi lebih memahami cara kerja komputer dari proses awal menyala hingga eksekusi program
• Tujuannya adalah membuat sendiri satu tulisan penjelasan yang kokoh, seperti yang dulu ingin penulis temukan
• Bagi pembaca yang merasa sudah tahu isinya atau tidak punya waktu, penulis menyarankan untuk membaca Bab 3 terlebih dahulu
• Tulisan berikutnya berlanjut ke Bab 1: The “Basics”

[GN⁺]

Komentar Hacker News

• Saya yang membuat ini. Terima kasih sudah membaca dan, sesuai gaya Hacker News, memberi tahu berbagai hal yang perlu diperbaiki. Putting the "You" in CPU masih sangat dalam proses pengerjaan, dan awalnya saya berencana merapikannya lagi, menambah isi, lalu mempostingnya ke HN sekitar minggu depan
  Saya berusia 17 tahun, keluar dari SMA setahun lalu, dan mulai bekerja penuh waktu di Hack Club(https://hackclub.com/). Sepanjang yang saya ingat saya selalu menulis program, dan sekitar 6 tahun lalu saya mulai homeschooling agar bisa lebih fokus pada pemrograman dan minat saya yang lain
  Saya belajar semuanya secara otodidak dan tidak pernah mengambil kelas sistem di universitas, dan saya tidak puas dengan jawaban saya sendiri atas pertanyaan “apa yang terjadi ketika sesuatu dijalankan”. Jadi saya menghabiskan sangat banyak waktu untuk mempelajarinya sedalam mungkin, dan dalam proses itu saya menyadari bahwa sistem operasi dan perangkat keras sangat menyenangkan untuk dipelajari, tetapi materi online tentang topik ini sering kali buruk
  Saat menelusuri, saya sering berakhir pada PDF slide kuliah tahun 2014, atau jawaban StackOverflow yang sebenarnya salah atau terlalu disederhanakan. Karena itu saya menulis Putting the "You" in CPU dengan harapan bisa menjadi materi yang lebih baik bagi orang yang ingin belajar bidang ini secara otodidak. Ini belum sempurna karena saya masih harus menulis beberapa paragraf lagi tentang SMP, tetapi menurut saya ini jauh lebih baik daripada kebanyakan materi yang pernah saya lihat. Saya juga baru pertama kali membuat gambar dan diagram, dan hasilnya makin bagus di bab-bab belakang; ada beberapa gambar di bagian akhir yang cukup saya banggakan
  Versi lengkapnya tersedia sebagai open source di GitHub: https://github.com/hackclub/putting-the-you-in-cpu

  • Akhir-akhir ini saya juga sering berpikir, “materi online seperti ini terlalu buruk.” Terutama saat mencari diagram blok Linux kernel yang rinci, cara kerja page table, perbandingan ABI pemanggilan fungsi di berbagai platform, detail protokol jaringan tingkat rendah, atau nomor PID Linux yang dipesan
    Kadang saya menemukan jawaban di thread Reddit, tetapi biasanya bercampur dengan banyak noise, dan saya juga ragu apakah Reddit tempat yang dapat diandalkan untuk menyimpan pengetahuan. StackOverflow sangat berfokus pada pertanyaan untuk menyelesaikan tugas tertentu, jadi jawabannya juga tak terelakkan pendek, dan karena itu sangat kurang membantu
    Untuk pengetahuan umum, sekarang saya biasanya langsung ke Wikipedia sambil melewati hasil pencarian Google yang rusak, tetapi Wikipedia juga punya batas dalam seberapa dalam ia membahas topik teknis. Rasanya kita butuh sebuah wiki yang mengumpulkan detail arsitektur internal komputer secara menyeluruh. Materinya tersebar di mana-mana, dan akan sangat bagus kalau terkumpul di satu tempat
  • Saya juga punya pertanyaan serupa di usia itu, dan saya menemukan banyak jawaban menarik di source code Linux. Tentu saja waktu itu semuanya jauh lebih sederhana. Khususnya, komunitas osdev dan dokumentasi arsitektur sistem Intel menjadi pemicu besar, dan kalau tidak salah bagian 3a atau 3b berisi banyak hal bagus
    Dokumen itu jauh lebih banyak memberi tahu tentang bagaimana dunia ini bisa dibuat, daripada bagaimana dunia saat ini benar-benar berjalan. Dengan melakukan OSDEV, Anda juga belajar banyak hal menarik seperti bagaimana prosesor 32-bit menggunakan addressing 36-bit lewat PAE, atau bagaimana prosesor 64-bit menggunakan addressing 52-bit demi memeras lebih banyak uang
    Anda juga jadi tahu mengapa komputer harus melakukan akrobat assembly level sistem untuk beralih dari mode 16-bit sampai ke long mode, mengapa mode 8-bit masih ada, dan sebagainya. Jika belajar pemuatan biner saja sudah terasa menarik, masih ada banyak hal yang akan mengejutkan. Misalnya, segmentasi memori masih ada di mode 64-bit, tetapi dalam long mode dipaksa menjadi pemetaan datar
  • Ini pekerjaan yang hebat. Ini materi pengantar yang bagus untuk pengembangan sistem operasi, dan meski detailnya banyak, tetap mudah dicerna. Bagian akhir catatan bab 2 #2 mungkin sebaiknya sedikit diperbaiki. Itu perlu mencerminkan bahwa paradigma asinkron di beberapa bahasa pemrograman adalah bentuk multitasking kooperatif. Di dalam proses, penggunaan multitasking kooperatif biasanya dianggap aman, meskipun apakah itu diinginkan atau tidak adalah persoalan lain. Setahu saya, Erlang tetap menggunakan preemptive demi ketahanan

• Saya suka materi seperti ini. Akhir-akhir ini saya mulai masuk ke dunia RISC-V, dan tampaknya jelas bahwa orang-orang yang ingin mendorong perangkat lunak bebas dan open source ke depan akan membutuhkan pengetahuan seperti ini agar perangkat lunak bisa berjalan baik di berbagai single-board computer baru yang bermunculan

  • Sebagai catatan, encoding instruksi RISC-V termasuk salah satu yang cukup aneh di antara hal-hal yang bisa Anda eksplorasi, kecuali mungkin Thumb-2. Ada alasan bagus mengapa ia dibuat seperti itu, tetapi kalau Anda berniat membaca hex dump, RISC-V tidak akan mempermudah Anda. Meski dari kebanyakan sudut pandang lain ia memang sederhana
  • Kalau Anda pernah belajar sampai tingkat sarjana atau lebih, rasanya programmer umumnya sudah tahu hal-hal seperti ini, bukan? Setidaknya kalau Anda tidak melewatkan kuliah arsitektur komputer dan sistem operasi
    Dalam kasus saya, saat belajar bagaimana komputer bekerja, hal yang umum dilakukan adalah mendefinisikan instruction set architecture, mengimplementasikan simulator dan assembler, lalu menulis assembly sendiri. Orang yang lebih serius bahkan mengimplementasikannya di FPGA atau menulis backend LLVM
    Hal yang sama juga berlaku di sisi sistem operasi. Belajar dengan mengimplementasikan kernel sendiri, atau setidaknya memodifikasi kernel yang sudah ada, adalah proses yang cukup umum

• Jika Anda ingin lebih memahami bagaimana komputer bekerja pada tingkat yang sangat dasar, saya sangat merekomendasikan buku Charles Petzold Code. Buku itu mulai dari prinsip pertama lalu naik sampai tingkat yang cukup tinggi

  • Jika Anda lebih suka belajar dengan membuat langsung, Nandgame https://nandgame.com juga bagus

• Salah satu hal yang dilakukan materi ini dengan baik adalah menunjukkan ekspektasi versus hasil belajar nyata dalam proses mengumpulkan informasi. Dengan pola seperti, “saya menduga x karena y, tetapi ternyata a karena b!”
  Menyingkirkan miskonsepsi sering kali merupakan tahap kunci dalam membentuk pengetahuan baru, dan akan membantu bila penulis mengakui bahwa pembaca yang memproses informasi harus melewati miskonsepsi mereka sendiri. Itu jauh lebih ramah bagi pembaca daripada sikap seperti, “ini jawaban yang benar, dan kalau Anda berpikir lain berarti Anda bodoh”

• Di bab 6, penjelasan tentang nilai kembalian fork() salah. Kebalik dari yang tertulis: pada induk, yang dikembalikan adalah PID anak, dan pada anak, yang dikembalikan adalah 0. Saya sudah membuat pull request untuk bagian ini

  • Terima kasih banyak, itu memang kesalahan saya. Saya sudah memperbaiki contoh kodenya dan menggabungkannya

• Dari penjelasan bahwa add eax, 512 diterjemahkan menjadi 05 00 02 00 00, disebutkan bahwa byte pertama 05 adalah opcode untuk menambahkan angka 16-bit ke register EAX, dan byte-byte sisanya adalah 512 (0x200) dalam little-endian
  Namun penjelasan ini hanya menjelaskan 3 byte pertama dari instruksi 5 byte itu. Saya jadi penasaran dua 00 sisanya itu apa. Mungkin maksudnya opcode tersebut menambahkan angka 32-bit ke EAX?

  • Bukan “he” melainkan “she”, dan benar. Sepertinya di bagian itu memang seharusnya tertulis 32-bit. Bagus sekali menangkapnya
  • Kalau yang dimaksud adalah x86, itu benar. Register eax lebarnya 32-bit, dan 16 bit terbawah dari register yang sama disebut ax

• Tulisan yang bagus. Sebagai pengembang web otodidak, saya merasa materi seperti ini sangat berharga. Ini membantu memahami dengan lebih konkret bagaimana sesuatu benar-benar bekerja, lepas dari berbagai lapisan abstraksi

• Kelihatannya materi yang bagus, cukup cepat masuk ke inti, dan sedikit menyenangkan juga. Tidak terlalu terasa seperti “tutorial monad” dibanding yang saya bayangkan. Saya berniat membaca lebih lanjut

  • Senang mendengarnya. Kalau nanti ada masukan, saya akan senang jika Anda memberi tahu

• Materi yang bagus. Namun saya masih punya satu pertanyaan tentang kernel. Di [0] dijelaskan bahwa shebang diproses di kernel dan diambil dari buf tanpa memuat seluruh berkas, sehingga selalu terpotong sesuai panjang buf
  Empat tahun lalu seseorang kesal karena kernel memotong path yang lebih dari 128 karakter, lalu ukuran buffer digandakan sehingga titik pemotongannya juga menjadi dua kali lipat. Jadi, di Linux saat ini, jika baris shebang melebihi 256 karakter, apa pun setelah 256 karakter akan hilang sepenuhnya
  Saya tidak mengerti kenapa path berkas milik seseorang dipotong diam-diam. Bukan pihak lain, justru kernel seharusnya tidak melakukan hal seperti itu. Path berkas 256 byte mungkin terdengar tidak masuk akal, tetapi string path+argumen 256 byte hampir pasti akan muncul pada suatu saat. Diam-diam merusak skrip itu salah
  [0]: https://cpu.land/how-to-run-a-program

  • Sebagai penulis, saya sangat setuju. Seharusnya orang tidak perlu memahami sampai ke logika eksekusi kernel hanya untuk mengerti batasan shebang. Ini desain yang bodoh, dan mungkin saya seharusnya lebih menekankan hal itu
    Beberapa tahun lalu seseorang mencoba membuat patch kernel agar shebang yang terlalu panjang setidaknya gagal dengan jelas, bukan gagal diam-diam. Namun itu menimbulkan masalah di NixOS. Sesuai gaya Nix, mereka sudah menggunakan shebang yang terlalu panjang dengan banyak path nix-store yang panjang. Sebelumnya memang terpotong diam-diam tetapi tetap berjalan; lalu tiba-tiba semua skrip seperti itu gagal dan kompatibilitas mundur pun rusak. Karena itu patch tersebut harus dibatalkan, dan sejak itu perubahan serupa tidak berhasil masuk
    Untuk detailnya, lihat https://lwn.net/Articles/779997/
  • Jangan menaruh argumen yang rumit di shebang. Shebang itu untuk memberi tahu lokasi interpreter dari berkas saat ini
    Shebang sendiri bahkan tidak bisa menangani lebih dari satu argumen dengan benar. Jika menulis #!/bin/program -args somescript, hasilnya akan dipisah menjadi ['/bin/program','-args somescript'], yang hampir selalu bukan hasil yang diinginkan. Ini khusus Linux, dan shebang juga tidak portabel secara universal di semua Unix
    Jika ingin melakukan hal yang rumit, lebih baik gunakan #!/bin/sh, lalu exec dari berkas saat ini dengan argumen yang dibutuhkan
    Satu hal yang tidak disebutkan di tautan itu adalah bahwa Anda bisa memakai env untuk mencari interpreter dari path saat ini. Misalnya, #!/usr/bin/env python3 akan menemukan python3 yang digunakan pengguna tanpa perlu tahu lokasinya
    Ini bisa berguna untuk skrip yang dijalankan di lingkungan virtual yang bekerja dengan menimpa PATH untuk interpreter Python. Namun untuk program yang diinstal, ini tidak boleh dilakukan. Program yang diinstal tidak boleh membiarkan pengguna mengendalikan interpreter mana yang dipakai, jadi harus menggunakan path absolut
    env punya opsi -S yang bisa mem-parsing baris perintah dari satu string untuk menangani keterbatasan ini. Meski begitu, dari sudut pandang seseorang yang sudah bertahun-tahun menghindari trik-trik kecil di baris shebang, itu paling banter terlihat seperti praktik yang meragukan
  • Yang lebih mengejutkan adalah buffer itu tidak disetel sama dengan ukuran blok disk. Biasanya 512 byte, tetapi tidak selalu begitu