不懂精簡指令集還敢說自己是程序員？
在上一篇文章《CPU進化論：復雜指令集》中我們從歷史的角度講述了復雜指令集出現的必然，隨著時間的推移，采用復雜指令集架構的CPU出現各種各樣的問題，面對這些問題一部分人開始重新思考指令集到底該如何設計。
在這一時期，兩個趨勢的出現促成一種新的指令集設計思想。
內存與編譯器
時間來到了1980s年代，此時容量“高達”64K的內存開始出現，內存容量上終于不再捉襟見肘，價格也開始急速下降，在1977年，1MB內存的價格高達$5000，要知道這可是1977年的5000刀，但到了1994年，1MB內存價格就急速下降到大概只有$6，這是第一個趨勢。
此外在這一時期隨著編譯技術的進步，編譯器越來越成熟，漸漸的程序員們開始依靠編譯器來生成匯編指令而不再自己手工編寫。
這兩個趨勢的出現讓人們有了更多思考。
化繁為簡
19世紀末20世紀初意大利經濟學家Pareto發現，在任何一組東西中，最重要的只占其中一小部分，約20%，其余80%盡管是多數，卻是次要的，這就是著名的二八定律，機器指令的執行頻率也有類似的規律。
大概80%的時間CPU都在執行那20%的機器指令，同時CISC中一部分比較復雜的指令并不怎么被經常用到，而且那些設計編譯器的程序員也更傾向于組合一些簡單的指令來完成特定任務。
與此同時我們在上文提到過的一位計算機科學家，被派去改善微代碼設計，但后來這老哥發現有問題的是微代碼本身，因此開始轉過頭來去思考微代碼這種設計的問題在哪里。
他的早期工作提出一個關鍵點，復雜指令集中那些被認為可以提高性能的指令其實在內部被微代碼拖后腿了，如果移除掉微代碼，程序反而可以運行的更快，并且可以節省構造CPU消耗的晶體管數量。
由于微代碼的設計思想是將復雜機器指令在CPU內部轉為相對簡單的機器指令，這一過程對編譯器不可見，也就是說你沒有辦法通過編譯器去影響CPU內部的微代碼運行行為，因此如果微代碼出現bug那么編譯器是無能為力的，你沒有辦法通過編譯器生成其它機器指令來修復問題而只能去修改微代碼本身。
此外他還發現，有時一些復雜的機器指令執行起來要比等價的多個簡單指令要。
這一切都在提示：為什么不直接用一些簡單到指令來替換掉那些復雜的指令呢?
精簡指令集哲學
基于對復雜指令集的思考，精簡指令集哲學誕生了，精簡指令集主要體現在以下三個方面：
1，指令本身的復雜度
精簡指令集的思想其實很簡單，干嘛要去死磕復雜的指令，去掉復雜指令代之以一些簡單的指令。
有了簡單指令CPU內部的微代碼也不需要了，沒有了微代碼這層中間抽象，編譯器生成的機器指令對CPU的控制力大大增強，有什么問題讓寫編譯器的那幫家伙修復就好了，顯然調試編譯器這種軟件要比調試CPU這種硬件要簡單很多。
注意，精簡指令集思想不是說指令集中指令的數量變少，而是說一條指令背后代表的動作更簡單了。
舉個簡單的例子，復雜指令集中的一條指令背后代表的含義是“吃飯”的全部過程，而精簡指令集中的一條指令僅僅表示“咀嚼一下”的其中一個小步驟。
博主在《你管這破玩意叫編程語言》一文中舉得例子其實更形象一些，復雜指令集下一條指令可以表示“給我端杯水”，而在精簡指令集下你需要這樣表示：
2，編譯器
精簡指令集的另一個特點就是編譯器對CPU的控制力更強。
在復雜指令集下，CPU會對編譯器隱藏機器指令的執行細節，就像微代碼一樣，編譯器對此無能為力。
而在精簡指令集下CPU內部的操作細節暴露給編譯器，編譯器可以對其進行控制，也因此，精簡指令集RISC還有一個有趣的稱呼：“Relegate Interesting Stuff to Compiler”，把一些有趣的玩意兒讓編譯器來完成。
3，load/store architecture
在復雜指令集下，一條機器指令可能涉及到從內存中取出數據、執行一些操作比如加和、然后再把執行結果寫回到內存中，注意這是在一條機器指令下完成的。
但在精簡指令集下，這絕對是大寫的禁忌，精簡指令集下的指令只能操作寄存器中的數據，不可以直接操作內存中的數據，也就是說這些指令比如加法指令不會去訪問內存。
畢竟數據還是存放在內存中的，那么誰來讀寫內存呢?
原來在精簡指令集下有專用的 load 和 store 兩條機器指令來負責內存的讀寫，其它指令只能操作CPU內部的寄存器，這是和復雜指令集一個很鮮明的區別。
你可能會好奇，用兩條專用的指令來讀寫內存有什么好處嗎?別著急，在本文后半部分我們還會回到load/store指令。
以上就是三點就是精簡指令集的設計哲學。
接下來我們用一個例子來看下RISC和CISC的區別。
兩數相乘
如圖所示就是最經典的計算模型，最右邊是內存，存放機器指令和數據，最左側是CPU，CPU內部是寄存器和計算單元ALU，進一步了解CPU請參考《你管這破玩意叫CPU?》
內存中的地址A和地址B分別存放了兩個數，假設我們想計算這兩個數字之和，然后再把計算結果寫回內存地址A。
我們分別來看下在CISC和在RISC下的會怎樣實現。
1，CISC
復雜指令集的一個主要目的就是讓盡可能少的機器指令來完成盡可能多的任務，在這種思想下CPU需要在從內存中拿到一條機器指令后“自己去完成一系列的操作”，這部分操作對外不可見。
在這種方法下，CISC中可能會存在一條叫做MULT的機器指令，MULT是乘法multiplication的簡寫。
當CPU執行MULT這條機器指令時需要：
從內存中加載地址A上的數，存放在寄存器中
從內存中夾雜地址B上的數，存放在寄存器中
ALU根據寄存器中的值進行乘積
將乘積寫回內存
以上這幾部統統都可以用這樣一條指令來完成：
- MULT A B
MULT就是所謂的復雜指令了，從這里我們也可以看出，復雜指令并不是說“MULT A B”這一行指令本身有多復雜，而是其背后所代表的任務復雜。
這條機器指令直接從內存中加載數據，程序員(寫匯編語言或者寫編譯器的程序員)根本就不要自己顯示的從內存中加載數據，實際上這條機器指令已經非常類似高級語言了，我們假設內存地址A中的值為變量a，地址B中的值為變量b，那么這條機器指令基本等價于高級語言中這樣一句：
- a = a * b;
這就是我們在上一篇《CPU進化論：復雜指令集》中提到的所謂抹平差異，semantic gap，抹平高級語言和機器指令之間的差異，讓程序員或者編譯器使用最少的代碼就能完成任務，因為這會節省程序本身占用的內存空間，要知道在在1977年，1MB內存的價格大概需要$5000，省下來的就是錢。
因為一條機器指令背后的操作很多，而程序員僅僅就寫了一行“MULT A B”，這行指令背后的復雜操作就必須由CPU直接通過硬件來實現，這加重了CPU 硬件本身的復雜度，需要的晶體管數量也更多。
接下來我們看RISC方法。
2，RISC
相比之下RISC更傾向于使用一系列簡單的指令來完成一項任務，我們來看下一條MULT指令需要完成的操作：
從內存中加載地址A上的數，存放在寄存器中
從內存中夾雜地址B上的數，存放在寄存器中
ALU根據寄存器中的值進行乘積
將乘積寫回內存
這幾步需要a)從內存中讀數據;b)乘積;c) 向內存中寫數據，因此在RISC下會有對應的LOAD、PROD、STORE指令來分別完成這幾個操作。
Load指令會將數據從內存搬到寄存器;PROD指令會計算兩個寄存器中數字的乘積;Store指令把寄存器中的數據寫回內存，因此如果一個程序員想完成上述任務就需要寫這些匯編指令：
- LOAD RA, A
- LOAD RB, B
- PROD RA, RB
- STORE A, RA
現在你應該看到了，同樣一項任務，在CISC下只需要一條機器指令，而在RISC下需要四條機器指令，顯然RISC下的程序本身所占據的空間要比CISC大，而且這對直接用匯編語言來寫程序的程序員來說是很不友好的，因為更繁瑣嘛!再來看看這樣圖感受一下：
但RISC設計的初衷也不是讓程序員直接使用匯編語言來寫程序，而是把這項任務交給編譯器，讓編譯器來生成機器指令。
標準從來都是一個好東西
讓我們再來仔細的看一下RISC下生成的幾條指令：
- LOAD RA, A
- LOAD RB, B
- PROD RA, RB
- STORE A, RA
這些指令都非常簡單，CPU內部不需要復雜的硬件邏輯來進行解碼，因此更節省晶體管，這些節省下來的晶體管可用于其它功能上。
最關鍵的是，注意，由于每一條指令都很簡單，執行的時間都差不多，因此這使得一種能高效處理機器指令的方法成為可能，這項技術是什么呢?
我們在《CPU遇上特斯拉，程序員的心思你別猜》這篇文章中提到過，這就是有名的流水線技術。
指令流水線
流水線技術是初期精簡指令集的殺手锏。
在這里我們還是以生產汽車(新能源)為例來介紹一下。
假設組裝一輛汽車需要經過四個步驟：組裝車架、安裝引擎、安裝電池、檢驗。
假設這每個步驟需要10分鐘，如果沒有流水線技術，那么生產一輛汽車的時間是40分鐘，只有第一輛汽車完整的經過這四個步驟后下一輛車才能進入生產車間。
這就是最初復雜指令集CPU的工作場景。
顯然這是相當低效的，因為當前一輛車在進行最后一個步驟時，前三個步驟：組裝車架、安裝引擎、安裝電池，這三個步驟的工人是空閑。
CPU的道理也是一樣的，低效的原因在于沒有充分利用資源，在這種方法下有人會偷懶。
但引入流水線技術就不一樣了，當第一輛車還在安裝引擎時后一輛車就可以進入流水線來組裝車架了，采用流水線技術，四個步驟可以同時進行，最大可能的充分利用資源。
原來40分鐘才能生產一輛車，現在有了流水線技術可以10分鐘就生產出一輛車。
注意，這里的假設是每個步驟都需要10分鐘，如果流水線每個階段的耗時不同，將顯著影響流水線的處理能力。
假如其中一個步驟，安裝電池，需要20分鐘，那么安裝電池的前一個和后一個步驟就會有10分鐘的空閑，這顯然不能充分利用資源。
精簡指令集的設計者們當然也明白這個道理，因此他們嘗試讓每條指令執行的時間都差不多一樣，盡可能讓流水線更高效的處理機器指令，而這也是為什么在精簡指令集中存在Load和Store兩條訪問內存指令的原因。
由于復雜指令集指令與指令之間差異較大，執行時間參差不齊，沒辦法很好的以流水線的方式高效處理機器指令(后續我們會看到復雜指令集會改善這一點)。
第一代RISC處理器即為全流水線設計，典型的就是五級流水線，大概1到2個時鐘周期就能執行一條指令，而這一時期的CISC大概5到10個時鐘周期才能執行一條指令，盡管RISC架構下編譯出的程序需要更多指令，但RISC精簡的設計使得RISC架構下的CPU更緊湊，消耗更少的晶體管(無需微代碼)，因此帶來更高的主頻，這使得RISC架構下的CPU完成相同的任務速度優于CISC。
有流水線技術的加持，采用精簡指令集設計的CPU在性能上開始橫掃其復雜指令集對手。
名揚天下
到了1980年代中期，采用精簡指令集的商業CPU開始出現，到1980年代后期，采用精簡指令集設計的CPU就在性能上輕松碾壓所有傳統設計。
到了1987年采用RISC設計的MIPS R2000處理器在性能上是采用CISC架構(x86)的Intel i386DX兩到三倍。
所有其它CPU生成廠商都開始跟進RISC，積極采納精簡指令集設計思想，甚至操作系統MINIX(就是那個Linus上大學時使用的操作系統)的作者Andrew Tanenbaum在90年代初預言：“5年后x86將無人問津”，x86正是基于CISC。
CISC迎來至暗時刻。
接下來CISC該如何絕地反擊，要知道Inter以及AMD (x86處理器兩大知名生產商) 的硬件工程師們絕非等閑之輩。
預知后事如何，請聽下回分解。
總結
CISC中微代碼設計的復雜性讓人們重新思考CPU到底該如何設計，基于對執行指令的重新審視RISC設計哲學應運而生。
RISC中每條指令更加簡單，執行時間比較標準，因此可以很高效的利用流水線技術，這一切都讓采用RISC架構的CPU獲得了很好性能。
面對RISC，CISC陣營也開始全面反思應如何應對挑戰。后續文章將繼續這一話題。
希望本文對大家理解精簡指令集有所幫助。
本文轉載自微信公眾號「碼農的荒島求生」，可以通過以下二維碼關注。轉載本文請聯系碼農的荒島求生公眾號。
