Dalam bahagian kedua artikel tentang simulator sistem komputer, saya akan terus bercakap dalam bentuk pengenalan yang mudah tentang simulator komputer, iaitu tentang simulasi platform penuh, yang paling kerap ditemui pengguna biasa, serta tentang jam demi masa. -model jam dan jejak, yang lebih biasa dalam kalangan pembangun.
Π Saya bercakap tentang simulator secara umum, serta tentang tahap simulasi. Sekarang, berdasarkan pengetahuan itu, saya mencadangkan untuk menyelam lebih dalam sedikit dan bercakap tentang simulasi platform penuh, cara mengumpul jejak, apa yang perlu dilakukan dengannya kemudian, serta tentang emulasi mikroarkitektur jam demi jam.
Simulator platform penuh, atau "Sendirian di padang bukan pahlawan"
Jika anda ingin mengkaji pengendalian satu peranti tertentu, contohnya, kad rangkaian, atau menulis perisian tegar atau pemacu untuk peranti ini, maka peranti sedemikian boleh disimulasikan secara berasingan. Walau bagaimanapun, menggunakannya secara berasingan daripada infrastruktur lain tidak begitu mudah. Untuk menjalankan pemacu yang sepadan, anda memerlukan pemproses pusat, memori, akses kepada bas data, dsb. Di samping itu, pemacu memerlukan sistem pengendalian (OS) dan susunan rangkaian untuk berfungsi. Di samping itu, penjana paket yang berasingan dan pelayan tindak balas mungkin diperlukan.
Simulator platform penuh mewujudkan persekitaran untuk menjalankan tindanan perisian yang lengkap, yang merangkumi segala-galanya daripada BIOS dan pemuat but kepada OS itu sendiri dan pelbagai subsistemnya, seperti tindanan rangkaian, pemacu dan aplikasi peringkat pengguna yang sama. Untuk melakukan ini, ia melaksanakan model perisian kebanyakan peranti komputer: pemproses dan memori, cakera, peranti input/output (papan kekunci, tetikus, paparan), serta kad rangkaian yang sama.
Di bawah ialah gambarajah blok set cip x58 daripada Intel. Simulator komputer platform penuh pada set cip ini memerlukan pelaksanaan kebanyakan peranti yang disenaraikan, termasuk yang berada di dalam IOH (Hab Input/Output) dan ICH (Hab Pengawal Input/Output), yang tidak digambarkan secara terperinci pada rajah blok. . Walaupun, seperti yang ditunjukkan oleh amalan, tidak banyak peranti yang tidak digunakan oleh perisian yang akan kami jalankan. Model peranti sedemikian tidak perlu dibuat.
Selalunya, simulator platform penuh dilaksanakan pada tahap arahan pemproses (ISA, lihat di bawah). ). Ini membolehkan anda membuat simulator itu sendiri dengan cepat dan murah. Tahap ISA juga bagus kerana ia kekal lebih kurang malar, tidak seperti, contohnya, tahap API/ABI, yang berubah lebih kerap. Di samping itu, pelaksanaan di peringkat arahan membolehkan anda menjalankan apa yang dipanggil perisian binari yang tidak diubah suai, iaitu, menjalankan kod yang telah disusun tanpa sebarang perubahan, sama seperti ia digunakan pada perkakasan sebenar. Dalam erti kata lain, anda boleh membuat salinan ("buang") cakera keras anda, tentukan ia sebagai imej untuk model dalam simulator platform penuh, dan voila! β OS dan program lain dimuatkan dalam simulator tanpa sebarang tindakan tambahan.
Prestasi simulator
Seperti yang dinyatakan di atas, proses simulasi keseluruhan sistem, iaitu, semua perantinya, adalah usaha yang agak perlahan. Jika anda juga melaksanakan semua ini pada tahap yang sangat terperinci, sebagai contoh, seni bina mikro atau logik, maka pelaksanaan akan menjadi sangat perlahan. Tetapi tahap arahan adalah pilihan yang sesuai dan membenarkan OS dan program untuk dilaksanakan pada kelajuan yang mencukupi untuk pengguna berinteraksi dengan mereka dengan selesa.
Di sini adalah sesuai untuk menyentuh topik prestasi simulator. Ia biasanya diukur dalam IPS (arahan sesaat), lebih tepat dalam MIPS (berjuta-juta IPS), iaitu bilangan arahan pemproses yang dilaksanakan oleh simulator dalam satu saat. Pada masa yang sama, kelajuan simulasi juga bergantung kepada prestasi sistem di mana simulasi itu sendiri berjalan. Oleh itu, mungkin lebih tepat untuk bercakap tentang "perlahan" simulator berbanding sistem asal.
Simulator platform penuh yang paling biasa di pasaran, seperti QEMU, VirtualBox atau VmWare Workstation, mempunyai prestasi yang baik. Ia mungkin tidak dapat dilihat oleh pengguna bahawa kerja sedang dijalankan dalam simulator. Ini berlaku terima kasih kepada keupayaan virtualisasi khas yang dilaksanakan dalam pemproses, algoritma terjemahan binari dan perkara menarik lain. Ini semua adalah topik untuk artikel berasingan, tetapi secara ringkasnya, virtualisasi ialah ciri perkakasan pemproses moden yang membolehkan simulator tidak mensimulasikan arahan, tetapi menghantarnya untuk pelaksanaan terus kepada pemproses sebenar, jika, sudah tentu, seni bina simulator dan pemproses adalah serupa. Terjemahan binari ialah terjemahan kod mesin tetamu ke dalam kod hos dan pelaksanaan seterusnya pada pemproses sebenar. Akibatnya, simulasi hanya sedikit perlahan, 5-10 kali, dan sering berjalan pada kelajuan yang sama seperti sistem sebenar. Walaupun ini dipengaruhi oleh banyak faktor. Sebagai contoh, jika kita ingin mensimulasikan sistem dengan beberapa dozen pemproses, maka kelajuan akan serta-merta menurun sebanyak beberapa dozen kali ini. Sebaliknya, simulator seperti Simics dalam versi terkini menyokong perkakasan hos berbilang pemproses dan secara berkesan menyelaraskan teras simulasi ke teras pemproses sebenar.
Jika kita bercakap tentang kelajuan simulasi mikroarkitektur, maka ia biasanya beberapa pesanan magnitud, kira-kira 1000-10000 kali lebih perlahan daripada pelaksanaan pada komputer biasa, tanpa simulasi. Dan pelaksanaan pada tahap elemen logik adalah lebih perlahan dengan beberapa urutan magnitud. Oleh itu, FPGA digunakan sebagai emulator pada tahap ini, yang boleh meningkatkan prestasi dengan ketara.
Graf di bawah menunjukkan anggaran pergantungan kelajuan simulasi pada butiran model.
Simulasi rentak demi rentak
Walaupun kelajuan pelaksanaannya rendah, simulator seni bina mikro adalah perkara biasa. Simulasi blok dalaman pemproses adalah perlu untuk mensimulasikan dengan tepat masa pelaksanaan setiap arahan. Salah faham mungkin timbul di sini - selepas semua, nampaknya, mengapa tidak hanya memprogramkan masa pelaksanaan untuk setiap arahan. Tetapi simulator sedemikian akan menjadi sangat tidak tepat, kerana masa pelaksanaan arahan yang sama mungkin berbeza daripada panggilan ke panggilan.
Contoh paling mudah ialah arahan capaian memori. Jika lokasi memori yang diminta tersedia dalam cache, maka masa pelaksanaan akan menjadi minimum. Jika maklumat ini tiada dalam cache ("cache miss"), maka ini akan meningkatkan masa pelaksanaan arahan dengan ketara. Oleh itu, model cache diperlukan untuk simulasi yang tepat. Walau bagaimanapun, perkara itu tidak terhad kepada model cache. Pemproses tidak hanya akan menunggu data diambil dari memori apabila ia tidak berada dalam cache. Sebaliknya, ia akan mula melaksanakan arahan seterusnya, memilih arahan yang tidak bergantung pada hasil bacaan daripada ingatan. Ini adalah apa yang dipanggil pelaksanaan "keluar dari perintah" (OOO, pelaksanaan tidak teratur), yang diperlukan untuk meminimumkan masa terbiar pemproses. Memodelkan blok pemproses yang sepadan akan membantu untuk mengambil kira semua ini apabila mengira masa pelaksanaan arahan. Di antara arahan ini, dilaksanakan sementara hasil bacaan dari ingatan ditunggu, operasi lompat bersyarat mungkin berlaku. Sekiranya keputusan keadaan tidak diketahui pada masa ini, sekali lagi pemproses tidak menghentikan pelaksanaan, tetapi membuat "tekaan", melaksanakan cawangan yang sesuai dan terus melaksanakan arahan secara proaktif dari titik peralihan. Blok sedemikian, dipanggil peramal cawangan, juga mesti dilaksanakan dalam simulator seni bina mikro.
Gambar di bawah menunjukkan blok utama pemproses, tidak perlu mengetahuinya, ia hanya ditunjukkan untuk menunjukkan kerumitan pelaksanaan mikroarkitektur.
Operasi semua blok ini dalam pemproses sebenar disegerakkan oleh isyarat jam khas, dan perkara yang sama berlaku dalam model. Simulator mikroarkitektur sedemikian dipanggil kitaran tepat. Tujuan utamanya adalah untuk meramal dengan tepat prestasi pemproses yang sedang dibangunkan dan/atau mengira masa pelaksanaan program tertentu, sebagai contoh, penanda aras. Jika nilai lebih rendah daripada yang diperlukan, maka ia perlu mengubah suai algoritma dan blok pemproses atau mengoptimumkan program.
Seperti yang ditunjukkan di atas, simulasi jam demi jam adalah sangat perlahan, jadi ia digunakan hanya apabila mengkaji momen tertentu operasi program, di mana perlu untuk mengetahui kelajuan sebenar pelaksanaan program dan menilai prestasi masa depan peranti yang prototaip sedang disimulasikan.
Dalam kes ini, simulator berfungsi digunakan untuk mensimulasikan baki masa berjalan program. Bagaimanakah gabungan penggunaan ini berlaku dalam realiti? Pertama, simulator berfungsi dilancarkan, di mana OS dan semua yang diperlukan untuk menjalankan program yang sedang dikaji dimuatkan. Lagipun, kami tidak berminat dengan OS itu sendiri, mahupun pada peringkat awal pelancaran program, konfigurasinya, dsb. Walau bagaimanapun, kami juga tidak boleh melangkau bahagian ini dan terus meneruskan untuk melaksanakan program dari tengah. Oleh itu, semua langkah awal ini dijalankan pada simulator berfungsi. Selepas program telah dilaksanakan pada saat yang menarik minat kami, dua pilihan adalah mungkin. Anda boleh menggantikan model dengan model jam demi kitaran dan meneruskan pelaksanaan. Mod simulasi yang menggunakan kod boleh laku (iaitu, fail program tersusun biasa) dipanggil simulasi dipacu pelaksanaan. Ini adalah pilihan simulasi yang paling biasa. Pendekatan lain juga mungkin - simulasi dipacu jejak.
Simulasi berasaskan jejak
Ia terdiri daripada dua langkah. Menggunakan simulator berfungsi atau pada sistem sebenar, log tindakan program dikumpulkan dan ditulis pada fail. Log ini dipanggil jejak. Bergantung pada perkara yang sedang diperiksa, jejak mungkin termasuk arahan boleh laku, alamat memori, nombor port dan maklumat gangguan.
Langkah seterusnya ialah "memainkan" jejak, apabila simulator jam demi jam membaca jejak dan melaksanakan semua arahan yang tertulis di dalamnya. Pada akhirnya, kami mendapat masa pelaksanaan sekeping program ini, serta pelbagai ciri proses ini, sebagai contoh, peratusan hits dalam cache.
Ciri penting untuk bekerja dengan jejak ialah determinisme, iaitu, dengan menjalankan simulasi mengikut cara yang diterangkan di atas, berulang kali kita menghasilkan semula urutan tindakan yang sama. Ini memungkinkan, dengan menukar parameter model (saiz cache, penimbal dan baris gilir) dan menggunakan algoritma dalaman yang berbeza atau menalanya, untuk mengkaji cara parameter tertentu mempengaruhi prestasi sistem dan pilihan yang memberikan hasil terbaik. Semua ini boleh dilakukan dengan model peranti prototaip sebelum mencipta prototaip perkakasan sebenar.
Kerumitan pendekatan ini terletak pada keperluan untuk menjalankan aplikasi terlebih dahulu dan mengumpul jejak, serta saiz besar fail jejak. Kelebihannya termasuk fakta bahawa sudah cukup untuk mensimulasikan hanya bahagian peranti atau platform yang diminati, manakala simulasi melalui pelaksanaan biasanya memerlukan model yang lengkap.
Jadi, dalam artikel ini kita melihat ciri simulasi platform penuh, bercakap tentang kelajuan pelaksanaan pada tahap yang berbeza, simulasi jam demi kitaran dan jejak. Dalam artikel seterusnya saya akan menerangkan senario utama untuk menggunakan simulator, baik untuk tujuan peribadi dan dari sudut pandangan pembangunan dalam syarikat besar.
Sumber: www.habr.com