Pertanyaan Mengapa Intel menyembunyikan inti RISC internal dalam prosesor mereka?


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

Awalnya jelas bagi saya bahwa Intel memutuskan untuk menyembunyikan arsitektur internal baru dan memaksa programmer untuk menggunakan "CISC shell". Berkat keputusan ini, Intel dapat sepenuhnya mendesain ulang arsitektur mikroprosesor tanpa merusak kompatibilitasnya, itu wajar.

Namun saya tidak mengerti satu hal, mengapa Intel masih menyimpan instruksi RISC internal yang disembunyikan selama bertahun-tahun? Mengapa mereka tidak membiarkan programmer menggunakan instruksi RISC seperti penggunaan instruksi x86 CISC yang lama?

Jika Intel mempertahankan kompatibilitas ke belakang untuk waktu yang lama (kita masih memiliki mode virtual 8086 di sebelah mode 64 bit), Mengapa mereka tidak mengijinkan kita mengkompilasi program sehingga mereka akan mengabaikan instruksi CISC dan menggunakan inti RISC secara langsung? Ini akan membuka cara alami untuk perlahan-lahan meninggalkan instruksi x86 yang ditetapkan, yang sudah ditinggalkan sekarang (ini adalah alasan utama mengapa Intel memutuskan untuk menggunakan inti RISC di dalam, kan?).

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


76
2018-04-27 15:27


asal


Jawaban:


Tidak, set instruksi x86 tentu tidak ditinggalkan. Ini populer seperti dulu. Alasan mengapa Intel menggunakan seperangkat instruksi mikro RISC secara internal adalah karena mereka dapat diproses lebih efisien.

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

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

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

Ini bukan pengaturan yang sempurna, tetapi biayanya cukup kecil, dan ini adalah pilihan yang jauh lebih baik daripada mendesain CPU untuk mendukung dua set instruksi yang benar-benar berbeda. (Dalam hal ini, mereka mungkin akan menciptakan a ketiga set micro-ops untuk penggunaan internal, hanya karena mereka dapat di-tweak dengan bebas untuk paling sesuai dengan arsitektur internal CPU)


78
2018-04-27 15:38



Jika Intel menjaga kompatibilitas ke belakang   begitu lama (kami masih memiliki virtual   8086 mode di sebelah 64 bit mode), Why   tidakkah mereka mengizinkan kami menyusun program   sehingga mereka akan mengabaikan instruksi CISC   dan menggunakan inti RISC secara langsung? Ini akan   cara alami terbuka untuk perlahan-lahan meninggalkan x86   set instruksi, yang tidak lagi digunakan   saat ini (inilah alasan utama mengapa   Intel memutuskan untuk menggunakan inti RISC di dalam,   kanan?).

Anda perlu melihat sudut bisnis ini. Intel benar-benar mencoba untuk menjauh dari x86, tetapi itu adalah angsa yang bertelur emas untuk perusahaan. XScale dan Itanium bahkan tidak pernah mendekati tingkat keberhasilan yang dimiliki oleh bisnis inti x86 mereka.

Apa yang pada dasarnya Anda minta adalah Intel untuk menggorok pergelangan tangan mereka sebagai ganti hangatnya fuzzies dari pengembang. Merusak x86 tidak sesuai dengan minat mereka. Apa pun yang membuat lebih banyak pengembang tidak harus memilih untuk menargetkan x86 merusak x86. Itu, pada gilirannya, meremehkan mereka.


15
2018-04-27 15:43



Jawaban yang sebenarnya sederhana.

Faktor utama di balik penerapan prosesor RISC adalah untuk mengurangi kompleksitas dan mendapatkan kecepatan. Kelemahan dari RISC adalah kepadatan instruksi yang berkurang, yang berarti bahwa kode yang sama dinyatakan dalam format RISC seperti memerlukan 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 sama.

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

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

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

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

Efek samping lain adalah bahwa RISC lebih sulit pada implementasi compiler. Lebih mudah untuk mengoptimalkan kompiler untuk CISC cpus. dll.

Intel tahu apa yang mereka lakukan.

Ini benar bahwa ARM memiliki modus kepadatan kode yang lebih tinggi yang disebut Jempol.


13
2018-03-23 23:07



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

Intel sudah lama membuat komitmen itu, (tentu saja, tentu saja), CPU mereka akan tetap kompatibel ke belakang. Orang ingin tahu itu, ketika mereka membeli komputer berbasis Intel yang baru, itu semua perangkat lunak mereka saat ini akan berjalan persis sama seperti pada komputer lama mereka. (Meskipun, semoga, lebih cepat!)

Selanjutnya, Intel tahu persis betapa pentingnya komitmen itu, karena mereka pernah mencoba cara yang berbeda. Persisnya berapa banyak orang kamu tahu dengan CPU Itanium?!?

Anda mungkin tidak menyukainya, tetapi satu keputusan itu, untuk tetap menggunakan x86, itulah yang menjadikan Intel salah satu nama bisnis paling dikenal di dunia!


4
2017-10-10 00:27



Jawaban jalf mencakup sebagian besar alasannya, tetapi ada satu detail menarik yang tidak disebutkan: Inti internal RISC seperti tidak dirancang untuk menjalankan instruksi yang mengatur sesuatu seperti ARM / PPC / MIPS. Pajak x86 tidak hanya dibayar dalam decoder yang haus kekuasaan, tetapi pada tingkat tertentu di seluruh inti. itu bukan hanya pengodean instruksi x86; setiap instruksi dengan semantik aneh.

Mari kita berpura-pura bahwa Intel memang menciptakan mode operasi di mana aliran instruksi adalah sesuatu selain x86, dengan instruksi yang dipetakan lebih langsung ke Uops. Mari kita juga berpura-pura bahwa setiap model CPU memiliki ISA-nya sendiri untuk mode ini, jadi mereka masih bebas untuk mengubah internal ketika mereka suka, dan mengekspos mereka dengan jumlah minimal transistor untuk instruksi-decode dari format alternatif ini.

Mungkin Anda masih hanya memiliki jumlah register yang sama, dipetakan ke keadaan arsitektur x86, sehingga OS x86 dapat menyimpan / memulihkannya pada switch konteks tanpa menggunakan set instruksi spesifik CPU. Ini mungkin tidak terlalu sulit, karena perangkat keras daftar-mengganti nama sudah ada. (Internal Uops sebenarnya referensi file register fisik, tetapi ISA RISC hipotetis kami tidak perlu).


Jika kita hanya memiliki dekoder alternatif tanpa perubahan ke tahap pipeline (unit eksekusi) nanti, ISA ini masih memiliki banyak keeksentrikan x86.  Ini tidak akan menjadi arsitektur RISC yang sangat bagus. Tidak ada instruksi tunggal yang sangat kompleks, tetapi beberapa kegilaan lain dari x86 masih akan ada di sana.

Sebagai contoh: shift kiri / kanan meninggalkan flag Overflow tidak terdefinisi, kecuali jika jumlah shift adalah satu, dalam hal ini OF = deteksi overflow yang biasa terjadi. Kegilaan serupa untuk berputar. Namun, instruksi RISC yang terpapar dapat memberikan pergeseran tanpa bendera dan seterusnya (memungkinkan penggunaan hanya satu atau dua dari beberapa uops yang biasanya masuk ke beberapa instruksi x86 yang rumit). Jadi ini tidak benar-benar bertahan sebagai argumen kontra utama.

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


Pengkodean instruksi mungkin tidak akan menjadi ukuran tetap, karena Uops tunggal dapat menyimpan banyak data. Lebih banyak data daripada yang masuk akal jika semua insns memiliki ukuran yang sama. Sebuah mikro-fusi tunggal dapat menambahkan 32bit langsung dan operan memori yang menggunakan mode pengalamatan dengan 2 register dan perpindahan 32bit. (Dalam SnB dan kemudian, hanya mode pengalamatan register tunggal yang dapat menggabungkan mikro dengan ALU ops).

Uops sangat besar, dan tidak terlalu mirip dengan instruksi ARM fixed-width. Satu set instruksi 32bit fixed-width hanya dapat memuat 16bit pada waktu yang bersamaan, sehingga pemuatan alamat 32-bit membutuhkan beban-segera-setengah / beban -tinggi-pendek. x86 tidak perlu melakukan itu, yang membantu tidak mengerikan dengan hanya register 15 GP yang membatasi kemampuan untuk menjaga konstanta di dalam register. (15 adalah bantuan besar lebih dari 7 register, tetapi dua kali lipat lagi untuk 31 membantu jauh lebih sedikit, saya pikir beberapa simulasi ditemukan. RSP biasanya bukan tujuan umum, jadi lebih seperti 15 register GP dan setumpuk.)


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", tapi semoga memberi penjelasan tentang alasannya.


2
2017-09-30 13:00



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

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


-3
2017-10-15 15:49