Mengapa Intel menyembunyikan inti RISC internal di prosesor mereka?

Dimulai dengan Pentium Pro (mikroarsitektur P6), Intel mendesain ulang mikroprosesornya dan menggunakan inti RISC internal di bawah instruksi CISC lama. Sejak Pentium Pro semua instruksi CISC dibagi menjadi beberapa bagian yang lebih kecil (uops) dan kemudian dijalankan oleh inti RISC.

Pada awalnya, jelas bagi saya bahwa Intel memutuskan untuk menyembunyikan arsitektur internal baru dan memaksa pemrogram untuk menggunakan "CISC shell". Berkat keputusan ini Intel dapat sepenuhnya mendesain ulang arsitektur mikroprosesor tanpa merusak kompatibilitas, itu masuk akal.

Namun saya tidak mengerti satu hal, mengapa Intel masih menyembunyikan instruksi RISC internal selama bertahun-tahun? Mengapa mereka tidak mengizinkan programmer menggunakan instruksi RISC seperti set instruksi use x86 CISC yang lama?

Jika Intel menyimpan kompatibilitas ke belakang begitu lama (kami masih memiliki mode virtual 8086 di samping mode 64 bit), Mengapa mereka tidak mengizinkan kami mengkompilasi program sehingga mereka akan melewati instruksi CISC dan menggunakan inti RISC secara langsung? Ini akan membuka cara alami untuk perlahan-lahan meninggalkan set instruksi x86, yang sekarang sudah tidak digunakan lagi (ini adalah alasan utama mengapa Intel memutuskan untuk menggunakan inti RISC di dalamnya, bukan?).

Melihat seri Intel 'Core i' baru yang saya lihat, mereka hanya memperluas set instruksi CISC menambahkan AVX, SSE4 dan lainnya.

Tidak, set instruksi x86 sudah pasti tidak digunakan lagi. Itu sepopuler sebelumnya. Alasan Intel menggunakan serangkaian instruksi mikro mirip RISC secara internal adalah karena mereka dapat diproses dengan lebih efisien.

Jadi CPU x86 bekerja dengan memiliki dekoder tugas yang cukup berat di frontend, yang menerima instruksi x86, dan mengubahnya menjadi format internal yang dioptimalkan, yang dapat diproses oleh backend.

Adapun mengekspos format ini ke program "eksternal", ada dua poin:

• ini bukan format yang stabil. Intel dapat mengubahnya di antara model CPU agar paling sesuai dengan arsitektur tertentu. Hal ini memungkinkan mereka untuk memaksimalkan efisiensi, dan keuntungan ini akan hilang jika mereka harus menggunakan format instruksi yang tetap dan stabil untuk penggunaan internal maupun eksternal.
• tidak ada yang bisa diperoleh dengan melakukannya. Dengan CPU yang sangat besar dan kompleks saat ini, decoder adalah bagian yang relatif kecil dari CPU. Harus mendekode instruksi x86 membuatnya lebih kompleks, tetapi CPU lainnya tidak terpengaruh, jadi secara keseluruhan, hanya ada sedikit yang bisa didapat, terutama karena frontend x86 masih harus ada di sana, untuk mengeksekusi kode "legacy" . Jadi Anda bahkan tidak akan menyimpan transistor yang saat ini digunakan pada frontend x86.

Ini bukanlah pengaturan yang sempurna, tetapi biayanya cukup kecil, dan ini adalah pilihan yang jauh lebih baik daripada mendesain CPU untuk mendukung dua set instruksi yang sama sekali berbeda. (Dalam hal ini, mereka mungkin akan menemukan rangkaian mikro-op ketiga untuk penggunaan internal, hanya karena itu dapat diubah secara bebas agar sesuai dengan arsitektur internal CPU)

Jawaban sebenarnya sederhana.

Faktor utama di balik implementasi prosesor RISC adalah untuk mengurangi kompleksitas dan mendapatkan kecepatan. Kelemahan dari RISC adalah kepadatan instruksi yang berkurang, yang berarti bahwa kode yang sama yang diekspresikan dalam format seperti RISC membutuhkan lebih banyak instruksi daripada kode CISC yang setara.

Efek samping ini tidak berarti banyak jika CPU Anda berjalan pada kecepatan yang sama dengan memori, atau setidaknya jika keduanya berjalan pada kecepatan yang cukup mirip.

Saat ini kecepatan memori dibandingkan dengan kecepatan CPU menunjukkan perbedaan jam yang besar. CPU saat ini terkadang lima kali atau lebih cepat dari memori utama.

Keadaan teknologi ini mendukung kode yang lebih padat, sesuatu yang disediakan CISC.

Anda dapat membantah bahwa cache dapat mempercepat CPU RISC. Tetapi hal yang sama dapat dikatakan tentang CPU CISC.

Anda mendapatkan peningkatan kecepatan yang lebih besar dengan menggunakan CISC dan cache daripada RISC dan cache, karena ukuran cache yang sama lebih berpengaruh pada kode kepadatan tinggi yang disediakan CISC.

Efek samping lainnya adalah RISC lebih keras pada implementasi compiler. Lebih mudah untuk mengoptimalkan kompiler untuk CPU CISC. dll.

Intel tahu apa yang mereka lakukan.

Ini benar bahwa ARM memiliki mode kepadatan kode yang lebih tinggi yang disebut Thumb.

Jika Intel menyimpan kompatibilitas ke belakang begitu lama (kami masih memiliki mode virtual 8086 di samping mode 64 bit), Mengapa mereka tidak mengizinkan kami mengkompilasi program sehingga mereka akan melewati instruksi CISC dan menggunakan inti RISC secara langsung? Ini akan membuka cara alami untuk perlahan-lahan meninggalkan set instruksi x86, yang sekarang sudah tidak digunakan lagi (ini adalah alasan utama mengapa Intel memutuskan untuk menggunakan inti RISC di dalamnya, bukan?).

Anda perlu melihat dari sudut bisnis ini. Intel sebenarnya telah mencoba untuk menjauh dari x86, tetapi angsa lah yang meletakkan telur emas bagi perusahaan. XScale dan Itanium tidak pernah mendekati tingkat kesuksesan yang dimiliki bisnis inti x86 mereka.

Apa yang pada dasarnya Anda minta adalah Intel untuk memotong pergelangan tangannya dengan imbalan bulu mata hangat dari pengembang. Meremehkan x86 bukanlah kepentingan mereka. Apa pun yang membuat lebih banyak pengembang tidak harus memilih untuk menargetkan x86 akan merusak x86. Itu, pada gilirannya, melemahkan mereka.

Jawabannya sederhana. Intel tidak mengembangkan CPU untuk pengembang ! Mereka mengembangkannya untuk orang-orang yang membuat keputusan pembelian , yang BTW, adalah apa yang dilakukan setiap perusahaan di dunia!

Intel sejak lama membuat komitmen bahwa, (dengan alasan, tentu saja), CPU mereka akan tetap kompatibel ke belakang. Orang-orang ingin tahu bahwa, ketika mereka membeli komputer berbasis Intel baru, bahwa semua perangkat lunak mereka saat ini akan berjalan persis sama seperti di komputer lama mereka. (Meskipun, semoga, lebih cepat!)

Lebih jauh lagi, Intel tahu persis betapa pentingnya komitmen itu, karena mereka pernah mencoba menempuh jalan yang berbeda. Persis berapa banyak orang yang Anda kenal dengan CPU Itanium?!?

Anda mungkin tidak menyukainya, tetapi satu keputusan itu, untuk tetap menggunakan x86, yang membuat Intel menjadi salah satu nama bisnis paling terkenal di dunia!

Jawaban @ jalf mencakup sebagian besar alasan, tetapi ada satu detail menarik yang tidak disebutkan: Inti seperti RISC internal tidak dirancang untuk menjalankan set instruksi seperti ARM / PPC / MIPS. Pajak x86 tidak hanya dibayarkan pada decoder yang haus daya, tetapi juga di seluruh inti. yaitu bukan hanya pengkodean instruksi x86; itu setiap instruksi dengan semantik aneh.

Anggaplah Intel membuat mode operasi dengan aliran instruksi selain x86, dengan instruksi yang dipetakan lebih langsung ke uops. Mari kita juga menganggap bahwa setiap model CPU memiliki ISA sendiri untuk mode ini, jadi mereka masih bebas untuk mengubah internal ketika mereka suka, dan mengeksposnya dengan jumlah transistor minimal untuk instruksi-dekode format alternatif ini.

Agaknya Anda masih hanya memiliki jumlah register yang sama, dipetakan ke status arsitektur x86, sehingga x86 OS dapat menyimpan / memulihkannya pada sakelar konteks tanpa menggunakan set instruksi khusus CPU. Tetapi jika kita membuang batasan praktis itu, ya kita dapat memiliki beberapa register lagi karena kita dapat menggunakan register temp tersembunyi yang biasanya disediakan untuk microcode ¹ .

Jika kita hanya memiliki dekoder alternatif tanpa perubahan ke tahap pipeline selanjutnya (unit eksekusi), ISA ini masih memiliki banyak eksentrisitas x86. Ini bukan arsitektur RISC yang bagus. Tidak ada instruksi tunggal yang akan menjadi sangat kompleks, tetapi beberapa kegilaan x86 lainnya akan tetap ada.

Misalnya: pergeseran kiri / kanan membiarkan bendera Overflow tidak ditentukan, kecuali hitungan shift adalah satu, dalam hal ini OF = deteksi luapan bertanda biasa. Kegilaan serupa untuk rotasi. Namun, instruksi RISC yang terekspos dapat memberikan pergeseran tanpa flag dan seterusnya (mengizinkan penggunaan hanya satu atau dua dari beberapa uops yang biasanya masuk ke beberapa instruksi x86 yang kompleks). Jadi ini tidak benar-benar berlaku sebagai argumen tandingan utama.

Jika Anda akan membuat decoder yang benar-benar baru untuk ISA RISC, Anda dapat memilihnya dan memilih bagian dari instruksi x86 untuk diekspos sebagai instruksi RISC. Ini agak mengurangi spesialisasi x86 dari inti.

Pengkodean instruksi mungkin tidak berukuran tetap, karena uops tunggal dapat menampung banyak data. Lebih banyak data daripada yang masuk akal jika semua insns berukuran sama. UOP mikro-fusi tunggal dapat menambahkan 32bit segera dan operan memori yang menggunakan mode pengalamatan dengan 2 register dan perpindahan 32bit. (Di SnB dan yang lebih baru, hanya mode pengalamatan register tunggal yang dapat melakukan sekering mikro dengan operasi ALU).

uops sangat besar, dan tidak terlalu mirip dengan instruksi ARM dengan lebar tetap. Set instruksi 32-bit dengan lebar tetap hanya dapat memuat 16-bit segera pada satu waktu, jadi memuat alamat 32-bit membutuhkan pasangan beban-langsung-rendah-setengah /-tinggi-langsung. x86 tidak harus melakukan itu, yang membantunya tidak menjadi buruk dengan hanya 15 register GP yang membatasi kemampuan untuk menyimpan konstanta di register. (15 adalah bantuan besar dari 7 register, tetapi menggandakan lagi menjadi 31 membantu jauh lebih sedikit, saya pikir beberapa simulasi ditemukan. RSP biasanya bukan tujuan umum, jadi lebih seperti 15 register GP dan tumpukan.)

Ringkasan TL; DR:

Bagaimanapun, jawaban ini bermuara pada "set instruksi x86 mungkin adalah cara terbaik untuk memprogram CPU yang harus dapat menjalankan instruksi x86 dengan cepat", tetapi mudah-mudahan dapat menjelaskan alasannya.

Format uop internal di front-end vs. back-end

Lihat juga mode fusi mikro dan pengalamatan untuk satu kasus perbedaan dalam apa yang dapat diwakili oleh format uop front-end vs. back-end pada CPU Intel.

Catatan kaki 1 : Ada beberapa register "tersembunyi" untuk digunakan sebagai sementara oleh microcode. Register ini diganti namanya seperti register arsitektural x86, sehingga instruksi multi-uop dapat dieksekusi out-of-order.

misalnya xchg eax, ecxpada CPU Intel mendekode sebagai 3 uops ( mengapa? ), dan tebakan terbaik kami adalah bahwa ini adalah uops mirip MOV yang melakukannya tmp = eax; ecx=eax ; eax=tmp;. Dalam urutan itu, karena saya mengukur latensi dari arah dst-> src pada ~ 1 siklus, vs. 2 untuk sebaliknya. Dan gerakan ini tidak seperti movinstruksi biasa ; mereka tampaknya bukan calon eliminasi perpindahan latensi-nol.

Lihat juga http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/ untuk penyebutan mencoba mengukur ukuran PRF secara eksperimental, dan harus memperhitungkan register fisik yang digunakan untuk menyimpan status arsitektural, termasuk register tersembunyi.

Di front-end setelah decoder, tetapi sebelum masalah / rename stage yang mengganti nama register ke file register fisik, format uop internal menggunakan nomor register yang mirip dengan nomor reg x86, tetapi dengan ruang untuk mengatasi register tersembunyi ini.

Format uop agak berbeda di dalam inti out-of-order (ROB dan RS), alias back-end (setelah tahap penerbitan / ganti nama). File register fisik int / FP masing-masing memiliki 168 entri di Haswell , jadi setiap bidang register dalam uop harus cukup lebar untuk menangani sebanyak itu.

Karena penggantian nama ada di HW, kami mungkin lebih baik menggunakannya, daripada memasukkan instruksi yang dijadwalkan secara statis langsung ke back-end. Jadi kita akan mulai bekerja dengan satu set register sebesar register arsitektur x86 + temporaries microcode, tidak lebih dari itu.

Bagian belakang dirancang untuk bekerja dengan pengubah nama bagian depan yang menghindari bahaya WAW / WAR, jadi kami tidak dapat menggunakannya seperti CPU dalam urutan meskipun kami menginginkannya. Itu tidak memiliki interlock untuk mendeteksi dependensi tersebut; yang ditangani oleh masalah / ganti nama.

Mungkin rapi jika kita dapat memasukkan uops ke back-end tanpa hambatan pada tahap masalah / ganti nama (titik tersempit dalam pipeline Intel modern, misalnya 4-lebar pada Skylake vs. 4 ALU + 2 beban + 1 port penyimpanan di bagian belakang). Tetapi jika Anda melakukan itu, saya rasa Anda tidak dapat menjadwalkan kode secara statis untuk menghindari penggunaan kembali register dan menginjak hasil yang masih diperlukan jika cache-miss menghentikan pemuatan untuk waktu yang lama.

Jadi kita cukup banyak memberi makan uops ke tahap masalah / ganti nama, mungkin hanya melewati decode, bukan cache uop atau IDQ. Kemudian kita mendapatkan OoO exec normal dengan deteksi bahaya yang waras. Tabel alokasi register hanya dirancang untuk mengganti nama 16 + beberapa register integer ke PRF integer 168-entri. Kami tidak dapat mengharapkan HW untuk mengganti nama set register logis yang lebih besar ke jumlah register fisik yang sama; itu akan membutuhkan RAT yang lebih besar.

Mengapa mereka tidak mengizinkan kami mengkompilasi program sehingga mereka akan melewati instruksi CISC dan menggunakan inti RISC secara langsung?

Selain jawaban sebelumnya, alasan lainnya adalah segmentasi pasar. Beberapa instruksi dianggap diimplementasikan dalam microcode daripada di perangkat keras, sehingga mengizinkan siapa pun untuk mengeksekusi operasi mikro sewenang-wenang dapat merusak penjualan CPU baru dengan instruksi CISC "baru" yang lebih berkinerja.