Adapun kode kernel, selain kode khusus arsitektur, yang merupakan bagian yang sangat kecil (1% sampai 5%?), semua kode sumber kernel adalah umum untuk semua arsitektur.
Tentang binari:
Sebenarnya di sebagian besar distribusi Linux, vmlinuz adalah tautan simbolik yang menunjuk ke kode kernel yang di-gzip; seperti vmlinuz-3.16.0-4-amd64 . Saya yakin OP berbicara tentang yang terakhir, namun menyebutkan yang pertama untuk kepentingan pembaca.
https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/anatomy_of_the_initrd_and_vmlinuz
Memang benar bahwa kode ARM memang lebih kecil, bahkan jika kernel tidak dikompresi, kode kernel di ARM sering kali dibuat khusus, dan kode yang diaktifkan jauh lebih sedikit, daripada di versi mitra Intel (mis. Intel memiliki banyak kartu video, meskipun hanya modul bertopik, sementara biasanya kernel ARM kustom hanya harus berurusan dengan yang ada di SoC).
Selain itu, membandingkan gumpalan biner acak yang sudah dikompresi mungkin tidak selalu menghasilkan hasil yang sebenarnya karena beberapa kebetulan yang aneh, biner yang lebih besar mungkin menjadi lebih kecil karena beberapa pengoptimalan kompresi.
Jadi pada kenyataannya, untuk membandingkan kernel biner secara efektif, Anda harus mengompilasinya dengan opsi yang identik, dan membiarkannya tidak terkompresi (atau mengompres hasil vmlinuzxxx berkas).
Kecocokan yang adil akan membandingkan binari lain yang tidak terkompresi misalnya /bin/ls , atau /usr/sbin/tcpdump , dan selanjutnya arsitektur yang mirip dengan yang kami coba cocokkan (mesin ARM sebagian besar masih 32-bit, namun sudah ada beberapa yang 64 bit)
Tak perlu dikatakan, kode yang sama yang dikompilasi di ARM akan selalu (jauh) lebih kecil karena kode mesin ARM adalah kode platform RISC. Ini juga memiliki subset instruksi kode mesin yang lebih kecil, yang menghasilkan kode yang lebih kecil. Di sisi lain, Intel memiliki rangkaian instruksi yang lebih besar, juga karena warisan kompatibilitas retro dengan beberapa generasi mikroprosesor.
Dari http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
Konsep CPU RISC adalah yang lama, dan juga sangat efisien. Dalam CPU RISC Anda memiliki beban kerja yang lebih kecil yang dijalankan oleh setiap instruksi, instruksi ini juga sangat sering dipecah menjadi I/O dan Memori untuk lebih menghilangkan overhead. Hal ini membuat penggunaan CPU dan waktu memori menjadi sangat efisien, tetapi juga dapat memerlukan beberapa kode besar di sisi perangkat lunak untuk membuat semuanya berfungsi. Ketika RISC pertama kali dikembangkan, itu adalah cara yang tepat karena akses memori dan HDD lambat. Instruksi besar dan rumit yang ditemukan di CPU x86 tidak praktis pada CPU lama dan tidak dapat mengimbangi sistem RISC.
Namun demikian, percakapannya tidak cukup lurus, karena chip Intel adalah monster yang kompleks saat ini, dan jauh di dalam lapisan pseudo-CISC mereka memiliki strategi dan desain RISC yang mendekode dan meniru opcode Intel seperti yang kita kenal.
Opcode ARM juga besar, dibandingkan dengan MIPS, karena ARM adalah prosesor murah dengan instruksi khusus yang didedikasikan untuk decoding video (sekitar 30% dari die prosesor didedikasikan untuk mereka).
Sebagai latihan singkat, ambil biner tcpdump dan empat arsitektur Linux yang dapat saya akses:
MIPS 32 bit -> 502.4K
ARM 32 bit -> 718K
Intel 32 bit (i386) -> 983K
Intel 64 bit (x86_64) -> 1,1M
Jadi kembali ke pertanyaan awal Anda:
- Kernel ARM "tumbuh" dalam ukuran yang lebih kecil karena arsitekturnya kurang beragam dalam perangkat keras dasar untuk distribusi tertentu.
- Namun, dan jauh lebih signifikan, ukurannya menjadi lebih kecil karena kode yang dihasilkan lebih efisien dan ringkas.
Kernel "biner" (vmlinuz atau lebih) adalah rangkaian kode singkat yang membuka kompresi kernel terkompresi lainnya. Mereka memiliki begitu banyak kesamaan karena sebagian besar dari awal file adalah sama (sehingga dikompres menjadi sama).
Perbedaan ukuran dari arsip sumber agak tidak relevan, sebagian besar perubahan dari satu versi ke versi berikutnya adalah baris diubah , dan driver baru ditambahkan (dan driver tidak muncul di kernel biner, mereka hanya digunakan di beberapa mesin dan biasanya modul eksternal).