網(wǎng)紅RISC-V有何特別之處?
20世紀(jì)90年代末,RISC和CISC爆發(fā)了一場大戰(zhàn),自那以后,大家都說RISC和CISC的區(qū)別沒那么重要了。許多人表示,指令集也就那么回事,對(duì)CPU沒什么太大的影響。但其實(shí)不然,指令集決定了我們可以輕松為微處理器做哪些優(yōu)化。
本文將介紹RISC-V處理器是如何設(shè)計(jì)指令集的,這樣的設(shè)計(jì)具有什么好處。
我最近一直在了解有關(guān)RISC-V指令集架構(gòu) (ISA) 的更多信息,說起來,關(guān)于RISC-V ISA有幾件事給我留下了非常深刻的印象: ◆ 它是一種RISC指令集,體積小,易于學(xué) 習(xí) 。 不管是任何人,只要有興趣學(xué)習(xí)微處理器,選它準(zhǔn)沒錯(cuò)。 ◆ 它在大學(xué)數(shù)字化設(shè)計(jì)教學(xué)中占據(jù)重要地位:為什么大學(xué)要學(xué)RISC-V。 ◆ 經(jīng)過巧妙地設(shè)計(jì),它允許CPU設(shè)計(jì)生產(chǎn)者使用RISC-V ISA打造高性能微處理器。 ◆ 無需授權(quán)費(fèi),且被設(shè)計(jì)成允許簡單的硬件實(shí)現(xiàn),按道理,專業(yè)愛好者可以在合理的時(shí)間內(nèi)完成他自己的RISC-V CPU設(shè)計(jì)。 ◆ 易于修改和使用的開源設(shè)計(jì):The Berkely Out-of-Order(BOOM)RISC-V處理器。
01
RISC的復(fù)仇
當(dāng)我開始更深入地理解RISC-V時(shí),意識(shí)到RISC-V是一種根本性的轉(zhuǎn)變,它回到了許多人認(rèn)為已經(jīng)過時(shí)的計(jì)算時(shí)代。在設(shè)計(jì)方面,RISC-V就像乘著時(shí)光機(jī)穿越回了上世紀(jì)八九十年代的經(jīng)典RISC時(shí)代。近年來,許多人指出RISC和CISC的區(qū)別不再重要,因?yàn)橄馎RM這樣的 RISC CPU已經(jīng)添加了太多的指令,很多指令相當(dāng)復(fù)雜,以至于它現(xiàn)在更像是一個(gè)混合的RISC CPU,而不是純粹的RISC CPU。而那些RISC CPU也是如此,比如PowerPC。 相比之下,RISC-V是RISC CPU真正的硬核。事實(shí)上,如果你在網(wǎng)上看過大家就RISC-V的討論,會(huì)發(fā)現(xiàn)有人聲稱RISC-V出自一些老學(xué)究式的RISC激進(jìn)分子之手,他們拒絕與時(shí)俱進(jìn)。 前ARM工程師Erin Shepherd幾年前就RISC-V寫過一篇評(píng)論,內(nèi)容很有意思: RISC-V ISA過分追求極簡主義。它非常強(qiáng)調(diào)最小化指令數(shù)、規(guī)范化編碼這些事。這種對(duì)極簡主義的追求導(dǎo)致了錯(cuò)誤的正交性(例如針對(duì)分支、調(diào)用和返回重用同一條指令)和對(duì)冗余指令的需求,這在指令大小和數(shù)量這兩個(gè)方面影響了代碼密度。 我向大家簡單介紹一下背景。讓代碼更小對(duì)性能有好處,因?yàn)檫@樣就可以更容易將正在運(yùn)行的代碼保存在高速CPU緩存中。 本文在此批評(píng)的是,RISC-V設(shè)計(jì)者太過于追求擁有小的指令集。盡管,這是RISC最初的目標(biāo)之一。然而,這樣做的弊端是,實(shí)際上程序在完成工作時(shí)將需要更多的指令,從而消耗更多的內(nèi)存空間。多年來,人們普遍認(rèn)為RISC處理器應(yīng)該增加更多的指令,變得更像CISC。其理論依據(jù)是,更專門化的指令可以替代對(duì)多個(gè)通用指令的使用。
02
壓縮指令和宏融合
然而,在CPU設(shè)計(jì)中有兩項(xiàng)特別的創(chuàng)新,這些創(chuàng)新從許多方面使添加更多復(fù)雜指令的策略變得多余:◆ 壓縮指令——在內(nèi)存中壓縮指令,并在CPU的第一階段進(jìn)行解壓。 ◆ 宏融合——將兩個(gè)或兩個(gè)以上由CPU讀取的簡單指令融合成一個(gè)復(fù)雜指令。 實(shí)際上ARM已經(jīng)采用了這兩種策略,而x86 CPU則采用了后者,所以這不能算是RISC-V的新招術(shù)。 然而,關(guān)鍵是RISC-V從這些策略中獲得了更大的優(yōu)勢,這里面有兩個(gè)重要原因: ◆ 它從一開始就添加了壓縮指令。 在 ARM 上使用的是 Thumb2 壓縮指令格式,這就必須將其作為一個(gè)單獨(dú)的ISA來添加以完成改造,這需要一個(gè)內(nèi)部模 式切換和單獨(dú)的解碼器來進(jìn)行處理。 RISC-V壓縮指令可以添加到具有400個(gè)額外邏輯門 (AND、OR、NOR、NAND 門) 的CPU上。 ◆ RISC執(zhí)著地控制獨(dú)特指令的數(shù)量得到了回報(bào),如此就有了更多的空間來容納壓縮指令。
03
指令編碼
這一部分需要進(jìn)行一些解釋。指令在RISC體系結(jié)構(gòu)上通常是32位(即比特)寬的。這些比特需要用來編碼不同的信息。例如,下面這樣一條指令: ADD x1, x4, x8 # x1 ← x4 + x8
這條指令將累加寄存器x4和x8的內(nèi)容,然后將結(jié)果存儲(chǔ)在x1中。我們需要多少比特來編碼,這取決于我們有多少寄存器。RISC-V和ARM64有32個(gè)寄存器??梢杂?比特表示數(shù)字32:
2? = 32
因?yàn)槲覀冃枰付?個(gè)不同的寄存器,所以我們需要總共15比特 (3×5) 來編碼操作數(shù) (累加操作的輸入)。 因此,我們想要在指令集中支持的東西越多,那么就會(huì)消耗掉那32比特中更多的比特。當(dāng)然,我們可以使用64位指令,但是這會(huì)消耗太多的內(nèi)存,從而降低性能。 通過刻意壓低指令的數(shù)量,RISC-V節(jié)省下更多的空間來添加表示我們正在使用的壓縮指令的比特。如果CPU看到指令中的某些位被設(shè)置為1,它就知道這條指令應(yīng)該作為一條壓縮指令來進(jìn)行解釋。 04
壓縮指令——二到一
這表示,我們可以將兩條16位寬的指令裝入一個(gè)32位字,而不是一個(gè)32位字只裝入一條指令。當(dāng)然,并不是所有的RISC-V指令都可以用16位格式表示。因此,32位指令的子集是根據(jù)它們的效用和使用頻率來挑選的。未壓縮指令可以接受3個(gè)操作數(shù) (輸入),而壓縮指令只能接受2個(gè)操作數(shù)。因此,壓縮后的ADD指令應(yīng)該如下所示:(# 號(hào)后為注釋)
C.ADD x4, x8 # x4 ← x4 + x8
RISC-V匯編程序使用前綴 c. 來指示一條指令應(yīng)該被匯編程序轉(zhuǎn)換成一個(gè)壓縮指令。但實(shí)際上你不需要去寫它。RISC-V匯編程序?qū)⒛軌蛟谶m當(dāng)?shù)臅r(shí)候選擇是壓縮指令還是非壓縮指令。 基本上,壓縮指令減少了操作數(shù)的數(shù)量。三個(gè)寄存器操作數(shù)將消耗15比特,而留給我們指定操作的就只剩下1比特了!因此,將操作數(shù)減少到兩個(gè),我們就能剩下6比特來指定操作碼 (要執(zhí)行的操作)。 這實(shí)際上接近于x86匯編的工作方式,在x86匯編中沒有足夠的比特來保留3個(gè)寄存器操作數(shù)。取而代之的是,x86使用一些比特來允許像ADD這樣的指令從內(nèi)存和寄存器中讀取輸入。 05
宏融合——一到二
但是,當(dāng)我們將指令壓縮與宏融合結(jié)合起來看時(shí),才能發(fā)現(xiàn)真正的收益。你看,如果CPU得到一個(gè)包含有兩個(gè)16比特的壓縮指令的32比特的字,它可以把這些合并成一條單一的復(fù)雜指令。這聽起來很荒謬,我們不是又回到原點(diǎn)了嗎?我們是不是又回到CISC風(fēng)格的CPU,這不正是我們?cè)噲D要避免的嗎? 不是的,因?yàn)槲覀儽苊庥么罅繌?fù)雜的指令、x86和ARM策略填充ISA規(guī)范。相反,我們基本上是通過各種簡單指令的組合來間接地表達(dá)一整套復(fù)雜指令。 在正常情況下,宏融合存在一個(gè)問題:雖然兩條指令可以被一條指令替換,但它們?nèi)匀粫?huì)消耗兩倍的內(nèi)存空間。但是使用指令壓縮,我們不會(huì)消耗更多的空間。我們做到了兩全其美。 讓我們來看看艾琳·謝潑德的一個(gè)例子。在她批評(píng)RISC-V ISA時(shí),展示了一個(gè)簡單的C函數(shù)。為了解釋起來更清楚一些,我把它重新寫了下來,內(nèi)容如下:
int get_index(int *array, int i) {
return array[i];
}
在x86上編譯成:
mov eax, [rdi+rsi*4]
ret
當(dāng)你在編程語言中調(diào)用函數(shù)時(shí),參數(shù)通常會(huì)根據(jù)既定的約定傳遞給寄存器中的函數(shù),這將取決于你所使用的指令集。在x86上,第一個(gè)參數(shù)放在寄存器 rdi 中,第二個(gè)放在 rsi 中。按照慣例,返回值必須放在寄存器eax中。 第一條指令將 rsi 的內(nèi)容乘以4。它包含了變量 i。為什么乘?因?yàn)閿?shù)組是由整數(shù)元素組成的,所以它們之間的間距為4個(gè)字節(jié)。因此,數(shù)組中的第三個(gè)元素的字節(jié)偏移量實(shí)際上是3×4=12。 然后,我們把它添加到rdi,它包含數(shù)組的基址。于是,我們得到了數(shù)組第 i 個(gè)元素的最終地址。我們讀取該地址的存儲(chǔ)單元的內(nèi)容,并將其存儲(chǔ)在 eax 中:大功告成。 在ARM上與之很相似:
LDR r0, [r0, r1, lsl #2]
BX lr ; return
這里我們不是乘以4,而是將寄存器r1向左平移2位,這就相當(dāng)于乘以 4。這也可能是更本真地表示了x86代碼中所發(fā)生的情況。在x86上,你只能乘以2、4、8,所有這些其實(shí)都可以通過左移1、2、3位來實(shí)現(xiàn)。 我想,x86描述中的剩余內(nèi)容你肯定都能猜得到了。現(xiàn)在讓我們進(jìn)入 RISC-V,真正有趣的內(nèi)容開始嘍?。? 號(hào)后為注釋)
SLLI a1, a1, 2 # a1 ← a1 << 2 ADD a0, a0, a1 # a0 ← a0 + a1 LW a0, a0, 0 # a0 ← [a0 + 0] RET
RISC-V上的寄存器a0和a1只是x10和x11的別名。它們是放置函數(shù)調(diào)用的第一個(gè)和第二個(gè)參數(shù)的地方。RET是一條偽指令(簡寫):
JALR x0, 0(ra) # sp ← 0 + ra
# x0 ← sp + 4 ignoring result
JALR 跳轉(zhuǎn)到 ra 引用返回地址的地址。ra 是 x1 的別名。 不管怎樣看,這似乎都很糟糕,對(duì)吧?對(duì)于像在表中執(zhí)行基于索引的查找并返回結(jié)果這樣簡單而常見的操作,需要兩倍的指令。 看上去確實(shí)很糟糕。這就是為什么艾琳·謝潑德強(qiáng)烈批評(píng)了 RISC-V 的設(shè)計(jì)選擇。她寫道: RISC-V 的簡化使解碼器 (即 CPU 前端) 更簡單,但代價(jià)是執(zhí)行更多的指令。然而,真正棘手的問題是擴(kuò)展流水線的寬度,而稍稍不規(guī)則甚至很不規(guī)則的指令其解碼都不會(huì)有太大的問題,主要難點(diǎn)是確定指令的長度,尤其是 x86,因?yàn)樗泻芏嗲熬Y。 然而,多虧了有指令壓縮和宏融合,我們可以扳回這一程。
C.SLLI a1, 2 # a1 ← a1 << 2 C.ADD a0, a1 # a0 ← a0 + a1 C.LW a0, a0, 0 # a0 ← [a0 + 0] C.JR ra
現(xiàn)在,這和 ARM 的例子中所占用的內(nèi)存空間是完全相同的。 好吧,接下來讓我們做一些 宏融合! 在 RISC-V 中允許將多個(gè)操作融合為一個(gè)的規(guī)則之一是,目標(biāo)寄存器得是相同的。ADD 和 LW(加載字) 指令就屬于這種情況。因此,中央處理器將把這些轉(zhuǎn)換成一條指令。 如果 SLLI 也是這樣的話,我們就可以把這三條指令融合成一條了。因此,CPU 會(huì)看到一些類似于更復(fù)雜的 ARM 指令的東西:
LDR r0, [r0, r1, lsl #2]
06
為何不能在代碼中直接編寫此宏操作
因?yàn)槲覀兊?ISA 不包含對(duì)它的支持!記住,可用的比特?cái)?shù)是有限的。為什么不把說明寫長一點(diǎn)呢?不行,那樣會(huì)消耗太多的內(nèi)存,并且會(huì)更快填滿寶貴的 CPU 緩存。然而,如果我們?cè)?CPU 內(nèi)部制造這些半復(fù)雜的長指令,也沒有什么可擔(dān)心的。CPU 在任何時(shí)候所面對(duì)的指令最多也不過幾百條。所以在每條指令上浪費(fèi)個(gè) 128 比特不是什么大問題。每個(gè)人都有足夠的硅。 因此,當(dāng)解碼器得到一條正常指令時(shí),它通常會(huì)把它轉(zhuǎn)換成一個(gè)或多個(gè)“微”操作。這些“微”操作是 CPU 實(shí)際要處理的指令。它們可以非常地“寬廣”,包含很多額外的有用信息。稱之為“微”似乎有些諷刺,因?yàn)樗鼈兤鋵?shí)很“廣”。然而事實(shí)上“微”指的是它們做的任務(wù)數(shù)量有限。
07
指令的復(fù)雜性
宏融合將解碼器的工作做了一點(diǎn)改變:不再是將一條指令轉(zhuǎn)換成多個(gè)微操作,而是將多個(gè)操作轉(zhuǎn)換成一個(gè)微操作。因此,在現(xiàn)代 CPU 中發(fā)生的事情看起來相當(dāng)奇怪:
-
首先,它通過壓縮將兩條指令合并為一條指令。
-
然后借助解壓把它分成兩部分。
-
通過宏融合將它們合并到一個(gè)操作中。
-
不能太復(fù)雜,否則無法在為每條指令分配的數(shù)量固定的時(shí)鐘周期內(nèi)完成。
-
不能太簡單,因?yàn)槟羌兇饩褪抢速M(fèi)CPU資源。執(zhí)行兩個(gè)微操作的時(shí)間是執(zhí)行一個(gè)微操作的時(shí)間的兩倍。
08
RISC的好處
好了,以上解釋了很多細(xì)節(jié),也許你很難一下子弄清楚重點(diǎn)是什么。為什么要進(jìn)行壓縮和融合?聽起來有很多額外的工作要做。首先,指令壓縮和zip壓縮完全不同?!皦嚎s”這個(gè)詞其實(shí)有點(diǎn)用詞不當(dāng),因?yàn)榱⒓唇鈮阂粭l已壓縮的指令非常簡單。做這件事并不浪費(fèi)時(shí)間。記住,對(duì)于RISC-V來說這很簡單。只需400個(gè)邏輯門,就可以完成解壓。 宏融合也是如此。雖然這看起來很復(fù)雜,但這些方法已經(jīng)在現(xiàn)代微處理器中得到了應(yīng)用。因此,這種復(fù)雜性的學(xué)費(fèi)早就已經(jīng)交過了。 然而,與ARM、MIPS和x86設(shè)計(jì)者不同的是,RISC-V設(shè)計(jì)者在開始設(shè)計(jì)ISA時(shí)就了解指令壓縮和宏融合?;蛘吒鼫?zhǔn)確地說,當(dāng)他們最初的ISA被設(shè)計(jì)出來的時(shí)候,那些競爭對(duì)手們并不知道這一點(diǎn)。當(dāng)設(shè)計(jì)64位版本的 x86 和 ARM 指令集時(shí),他們可能已經(jīng)考慮到了這一點(diǎn)。那么,為什么他們沒有這樣做呢,我們只能揣測??赡苁沁@些公司制作新的ISA時(shí),不喜歡過多地偏離早期版本吧。通常它更著重于消除以往明顯的錯(cuò)誤,而不是顛覆之前的理論基礎(chǔ)。 通過對(duì)第一個(gè)最小指令集展開各種測試,RISC-V的設(shè)計(jì)者有了兩個(gè)重要的發(fā)現(xiàn):
-
通常RISC-V程序占用的內(nèi)存空間接近或少于任何其他CPU體系結(jié)構(gòu),包括x86,鑒于x86是CISC ISA,所以被公認(rèn)是最節(jié)省空間的。
-
它需要執(zhí)行的微操作數(shù)比其他ISA更少。
09
RISC-V設(shè)計(jì)策
RISC-V利用了我們當(dāng)今對(duì)現(xiàn)代CPU的了解,并用這些知識(shí)指導(dǎo)了他們?cè)谠O(shè)計(jì)時(shí)的選擇。例如,我們知道:-
如今,CPU內(nèi)核會(huì)提前做分支預(yù)測。它們的預(yù)測正確率超過90%。
-
CPU內(nèi)核是超標(biāo)量體系結(jié)構(gòu)的,這意味著它們?cè)诓⑿袌?zhí)行多條指令。
-
使用無序執(zhí)行做到超標(biāo)量體系結(jié)構(gòu)。
-
它們是流水線式的。
10
業(yè)界有什么說法?
好吧,從理論上這聽起來可能很好,但在現(xiàn)實(shí)世界中也果真如此嗎?科技公司對(duì)此有什么看法?他們是否認(rèn)為RISC-V ISA比商業(yè)ISA(如ARM)提供了實(shí)實(shí)在在的好處? RISC-V甚至不在備選的采購清單上,但隨著Esperanto的工程師們對(duì)它越來越多的研究,他們漸漸意識(shí)到它不僅僅是一個(gè)玩具或者是一個(gè)教學(xué)工具?!拔覀冋J(rèn)為RISC-V(相對(duì)于Arm或MIPS或SPARC)可能會(huì)損失30%到40%的編譯效率,因?yàn)樗唵瘟?。”Ditzel說?!暗覀兊木幾g器專業(yè)人員對(duì)它進(jìn)行了基準(zhǔn)測試,難以置信的是只有1%左右。” Esperanto Technologies現(xiàn)在只是一家小公司。像英偉達(dá)這樣擁有大量經(jīng)驗(yàn)豐富的芯片設(shè)計(jì)師和資源的大公司呢?英偉達(dá)在他們的板卡上使用了一種叫做“獵鷹”的通用處理器。在評(píng)估備選方案時(shí),RISC-V名列前茅。免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場,如有問題,請(qǐng)聯(lián)系我們,謝謝!