做RISC-V自定義擴(kuò)展最難的不是寫那條指令的邏輯而是把工具鏈打通。我說的是這個(gè)場景你在FPGA上寫好了一個(gè)自定義加速指令邏輯仿真全都通過了結(jié)果回過來想在軟件側(cè)驗(yàn)證匯編器報(bào)不認(rèn)識、反匯編器顯示亂碼、GCC壓根不讓你從C代碼里調(diào)它。沒錯(cuò)新指令真正跑起來的完整流程RISC-V工具鏈適配是繞不過去的一關(guān)。這篇內(nèi)容就是我完整走通這條鏈路后的實(shí)戰(zhàn)記錄從指令編碼設(shè)計(jì)、binutils改造、GCC內(nèi)置函數(shù)接入到Spike和QEMU模擬器驗(yàn)證一條龍拆開講清楚附上可以直接復(fù)現(xiàn)的操作步驟適合正在搞RISC-V自定義擴(kuò)展但卡在工具鏈上的工程師也適合剛接觸RISC-V指令集、想搞懂工具鏈內(nèi)部是怎么工作的同學(xué)。1. 為什么要把一條新指令塞進(jìn)RISC-V工具鏈1.1 自定義指令到底能解決什么實(shí)際問題先別急著改代碼想清楚你要不要做這件事。RISC-V之所以在定制化場景里這么受歡迎就是因?yàn)樗o了你一個(gè)開口讓你能在指令集層面上為特定負(fù)載加速。最常見的幾個(gè)場景算法里的熱點(diǎn)計(jì)算比如矩陣乘加、卷積、FFT中的蝶形運(yùn)算用一條指令替代好幾條。AI推理中的量化運(yùn)算典型的如乘加飽和、移位取整組合硬件一條指令干完軟件少寫十幾條。加解密里的位變換操作比如國密算法中大量用到的循環(huán)移位、字節(jié)置換。網(wǎng)絡(luò)包處理里的位域提取、校驗(yàn)和計(jì)算。我這次拿來做例子的是一條自定義乘加指令運(yùn)算語義是rd rs1 * rs2 rd。選它是因?yàn)榻Y(jié)構(gòu)足夠簡單R型和乘加運(yùn)算大家都熟不至于把精力浪費(fèi)在理解算法上能集中精力看工具鏈適配本身。但這里有個(gè)必須提前說的判斷如果你的指令功能用兩三行普通指令就能表達(dá)或者編譯器優(yōu)化本身就能生成差不多的序列那自定義指令帶來的收益可能還不如它帶來的工程成本大。工具鏈適配、模擬器維護(hù)、軟件生態(tài)兼容這些事都是要還的。一般來說只有當(dāng)這個(gè)操作在一個(gè)算法里出現(xiàn)頻率極高、且普通指令序列加上數(shù)據(jù)搬移的開銷確實(shí)很大時(shí)自定義指令才劃算。1.2 先分清路線非標(biāo)準(zhǔn)擴(kuò)展與標(biāo)準(zhǔn)擴(kuò)展RISC-V的擴(kuò)展有兩條路。一條是走標(biāo)準(zhǔn)擴(kuò)展流程比如B擴(kuò)展位操作、P擴(kuò)展DSP你設(shè)計(jì)一套指令寫提案走社區(qū)評審進(jìn)規(guī)范和工具鏈這個(gè)過程以年為單位適合要大規(guī)模商用、要生態(tài)兼容的團(tuán)隊(duì)。另一條就是非標(biāo)準(zhǔn)擴(kuò)展也叫自定義擴(kuò)展直接使用指令集規(guī)范里預(yù)留的custom opcode空間自己定義編碼自己改工具鏈今天設(shè)計(jì)明天就能跑代價(jià)是代碼沒法直接跑到別的RISC-V核上除非對方也支持你這套擴(kuò)展。我走的是非標(biāo)準(zhǔn)擴(kuò)展這條路這也是絕大多數(shù)做定制芯片、加速器團(tuán)隊(duì)的實(shí)際選擇。RISC-V規(guī)范在opcode map里預(yù)留了四個(gè)custom空間對應(yīng)opcode字段的四個(gè)編碼值。這些編碼的標(biāo)準(zhǔn)指令集部分沒有分配任何官方指令就是專門留給用戶做擴(kuò)展的。我在例子里用的是CUSTOM-0這個(gè)空間opcode是7位二進(jìn)制0001011十六進(jìn)制0x0b。這個(gè)空間夠不夠用后面接著說。1.3 一條新指令跑起來要打通哪幾道關(guān)把這條路走通你會(huì)發(fā)現(xiàn)工具鏈不是一個(gè)軟件是一串環(huán)環(huán)相扣的組件。簡單列一下你寫的這條指令從匯編代碼到CPU執(zhí)行中間都要經(jīng)過誰binutils里的gas匯編器把cma這個(gè)助記符和寄存器操作數(shù)編碼成二進(jìn)制指令。binutils里的objdump反匯編器把二進(jìn)制指令反向翻譯回可讀的匯編文本沒有它你調(diào)試時(shí)會(huì)非常痛苦。GCC編譯器讓你能在C代碼層面直接寫__builtin_riscv_cma(...)生成這條指令或者起碼別在編譯到內(nèi)聯(lián)匯編時(shí)出岔子。鏈接器嚴(yán)格說鏈接器不太需要改但如果你要給新指令單獨(dú)安排一個(gè)擴(kuò)展名讓GCC識別鏈接時(shí)多多少少要確認(rèn)相關(guān)選項(xiàng)傳對了。模擬器Spike或QEMU。你要在指令集模擬器上執(zhí)行到這條指令的時(shí)候它得知道這條二進(jìn)制該干什么否則直接報(bào)非法指令。硬件或FPGA模擬器過了之后最后要落到RTL里去執(zhí)行這條指令。這里面每一環(huán)都有自己的一套登記機(jī)制。我的經(jīng)驗(yàn)是先在做任何修改之前把這條鏈路的順序理清楚因?yàn)楹笠画h(huán)節(jié)的報(bào)錯(cuò)原因經(jīng)常在前一環(huán)節(jié)改錯(cuò)地方是新手最容易踩的坑。2. 動(dòng)手前設(shè)計(jì)指令編碼與工具鏈環(huán)境準(zhǔn)備2.1 先設(shè)計(jì)指令編碼位域怎么分配工具鏈適配之前第一步一定是把指令編碼定死。編碼沒定后面所有地方的MATCH、MASK你都沒法填。RISC-V的R型指令格式固定是7位funct7、5位rs2、5位rs1、3位funct3、5位rd、7位opcode總共32位。我的自定義乘加指令cma rd, rs1, rs2用R型安排在CUSTOM-0空間里字段分配如下字段位數(shù)本例取值含義funct770000000功能碼高位rs25由匯編器填充源寄存器2rs15由匯編器填充源寄存器1funct33000功能碼低位rd5由匯編器填充目的寄存器同時(shí)也是累加器opcode70001011 (0x0b)CUSTOM-0在這個(gè)編碼里funct7和funct3都是0所以這條指令作為32位整數(shù)的匹配值MATCH_CMA就是0x0000000b。映射表里還有一個(gè)MASK_CMA表示哪些位是固定不變的。它的作用是一條32位指令跟MASK_CMA做按位與之后如果結(jié)果等于MATCH_CMA就說明這條指令屬于cma。rs1、rs2、rd是寄存器變量這些位要清零所以#define MATCH_CMA 0x0000000b #define MASK_CMA 0xfe00707fMASK怎么來的funct7這7位掩碼左移到25位是0xfe000000funct3這3位掩碼左移到12位是0x00007000opcode這7位掩碼是0x0000007f三者相或就是0xfe00707f。一個(gè)很容易忽略但特別重要的問題4個(gè)custom空間雖然大但你得規(guī)劃空間。CUSTOM-0這個(gè)opcode下面funct7有128種組合funct3有8種組合理論上還能塞進(jìn)去1024條R型指令。但實(shí)際使用時(shí)要記得給每條指令留出清晰的funct7/funct3分配表不然第幾十條擴(kuò)展指令往下加的時(shí)候編碼表會(huì)亂成一鍋粥。2.2 工具鏈組件與代碼倉庫選擇接下來說工具鏈。做RISC-V工具鏈適配主流有兩個(gè)起點(diǎn)一個(gè)是riscv-gnu-toolchain這個(gè)官方倉庫里面用子模塊方式把binutils、gcc、newlib和glibc組織在一起另一個(gè)是riscv-collab的riscv-binutils-gdb、riscv-gcc倉庫適合你只需要單獨(dú)改某一環(huán)的場景。我的建議是第一遍做適配用riscv-gnu-toolchain原因是它幫你把版本對齊了幾個(gè)子模塊的版本是互相測試過的不會(huì)出現(xiàn)你改了binutils但GCC版本不兼容這種問題。后面熟練了再拆開單獨(dú)維護(hù)。版本上的經(jīng)驗(yàn)binutils建議2.40以上GCC建議12以上。這兩個(gè)版本開始RISC-V后端對非標(biāo)準(zhǔn)擴(kuò)展的命名和子集管理機(jī)制相對穩(wěn)定網(wǎng)上能查到的資料也對得上。太老的版本riscv_multi_subset_supports這類接口的位置和實(shí)現(xiàn)都不一樣照著新代碼改到老版本上會(huì)踩坑。2.3 搭建編譯環(huán)境與最小驗(yàn)證工程環(huán)境上我最推薦的就是Linux x86_64機(jī)器裝好必要依賴后拉代碼編譯。編譯配置大概是這樣git clone --recursive https://github.com/riscv-collab/riscv-gnu-toolchain cd riscv-gnu-toolchain mkdir build cd build ../configure --prefix/opt/riscv --with-archrv64gc make -j$(nproc) linux這里--with-archrv64gc是默認(rèn)架構(gòu)參數(shù)我們用自己的擴(kuò)展名字之后GCC的-march參數(shù)可以覆蓋這個(gè)默認(rèn)值。同時(shí)我建議先建一個(gè)最小驗(yàn)證工程目錄里放一個(gè)測試匯編文件和一個(gè)Makefile。后面每改一個(gè)組件就跑一遍這個(gè)測試能第一時(shí)間定位問題在哪一環(huán)。我的測試文件和Makefile大概是這樣的# test.S .text .globl _start _start: li a0, 3 li a1, 4 li a2, 5 cma a0, a1, a2 # a0 3 4 * 5 23 li a7, 93 ecall # 退出Linux下CROSS ? riscv64-unknown-linux-gnu- all: test.bin test.o: test.S $(CROSS)gcc -c -o $ $ test.elf: test.o $(CROSS)gcc -static -o $ $ test.bin: test.elf $(CROSS)objcopy -O binary $ $ dump: test.elf $(CROSS)objdump -d $注意這一步先不要加cma因?yàn)榇藭r(shí)匯編器還不認(rèn)識它。編譯能過、objdump能出正常的反匯編說明環(huán)境本身沒問題接下來改工具鏈才有意義。3. binutils適配先讓匯編器和反匯編器認(rèn)指令3.1 指令表修改riscv-opc.h與riscv-opc.cbinutils對RISC-V指令的登記核心在兩個(gè)文件里。第一個(gè)是include/opcode/riscv-opc.h里面用DECLARE_INSN宏聲明指令第二個(gè)是opcodes/riscv-opc.c里面有一個(gè)riscv_opcodes[]數(shù)組數(shù)組里每一項(xiàng)描述一條指令的助記符、參數(shù)格式、匹配值、掩碼、所屬擴(kuò)展類別。我們先改riscv-opc.h在文件里加上一行聲明DECLARE_INSN(cma, MATCH_CMA, MASK_CMA)這行宏展開之后會(huì)聲明一個(gè)外部對象對應(yīng)這條指令的匹配信息。然后在riscv-opc.c的riscv_opcodes[]數(shù)組里加一條記錄。數(shù)組里每一條的字段結(jié)構(gòu)大致是助記符、所屬子集、操作數(shù)格式、match、mask、匹配函數(shù)、指令類別。加在我們的指令后面{cma, xcustom, d,s,t, MATCH_CMA, MASK_CMA, match_opcode, INSN_CLASS_XCUSTOM },這里重點(diǎn)解釋兩個(gè)東西。第一個(gè)是操作數(shù)格式d,s,t。在binutils的RISC-V后端里d表示rd目的寄存器s和t表示rs1、rs2源寄存器。助記符后面的字符串決定了匯編器怎么解析這條指令的操作數(shù)。有些指令是立即數(shù)操作數(shù)會(huì)用I表示12位立即數(shù)有些是u、j這種跳轉(zhuǎn)偏移。如果你自定義指令里有立即數(shù)要先搞清楚自己想用的格式有沒有現(xiàn)成的字母沒有的話還得在gas/config/tc-riscv.c里擴(kuò)展操作數(shù)解析邏輯。這一步很容易被低估實(shí)際改起來比R型指令麻煩得多。第二個(gè)是INSN_CLASS_XCUSTOM這個(gè)類別。binutils的RISC-V后端用riscv_insn_class枚舉來管理指令屬于哪一類I類、M類、A類這些都是預(yù)設(shè)的。xcustom這種非標(biāo)準(zhǔn)擴(kuò)展需要你在對應(yīng)的枚舉里自己加一個(gè)類別然后在gas的subset支持判斷里給它放行。3.2 匯編器gas側(cè)把新擴(kuò)展注冊進(jìn)子集在include/opcode/riscv.h里的riscv_insn_class枚舉中加上一個(gè)成員enum riscv_insn_class { INSN_CLASS_I, INSN_CLASS_M, INSN_CLASS_A, ... INSN_CLASS_XCUSTOM, ... };然后改gas/config/tc-riscv.c里的riscv_multi_subset_supports函數(shù)。這個(gè)函數(shù)的職責(zé)就是回答一個(gè)問題某條指令屬于某個(gè)指令類別當(dāng)前匯編時(shí)啟用的ISA擴(kuò)展是否包含該類別。不在這里放行匯編器看到cma會(huì)直接報(bào)錯(cuò)。switch (insn_class) { case INSN_CLASS_XCUSTOM: return riscv_subset_supports(xcustom); ... }還要在riscv_subset_supports相關(guān)的解析里讓xcustom這個(gè)字符串能被識別為合法擴(kuò)展名。RISC-V規(guī)范規(guī)定的擴(kuò)展名規(guī)則里以x開頭的是非標(biāo)準(zhǔn)擴(kuò)展binutils在這方面是支持解析的但不同版本對這個(gè)子集的字符串解析位置略有差異。新一點(diǎn)的版本還會(huì)檢查子集的依賴性有些后端會(huì)要求x擴(kuò)展必須掛在某個(gè)基礎(chǔ)ISA之上比如rv64gc_xcustom這種寫法。我建議在測試匯編文件里用-marchrv64gc_xcustom的方式來指定架構(gòu)。改了之后重編binutils再用交叉編譯工具試一下riscv64-unknown-linux-gnu-as -marchrv64gc_xcustom -o test.o test.S如果這條命令能過說明匯編器已經(jīng)認(rèn)了你的新指令。這一步走通了后面的東西就有了地基。3.3 反匯編器讓objdump看懂你的指令很多人在這一步會(huì)有個(gè)誤解以為反匯編器是另一套表。實(shí)際上binutils里反匯編和匯編用的是同一張riscv_opcodes[]表你給匯編器加的cma記錄objdump天然就能用了。它按match和mask去匹配指令的二進(jìn)制編碼匹配上之后把d,s,t格式翻譯回寄存器和助記符。所以這一步基本不用額外改代碼你要做的是編譯完整的binutils之后用objdump -d驗(yàn)證剛才編譯出來的目標(biāo)文件riscv64-unknown-linux-gnu-objdump -d test.o正常情況下應(yīng)該看到0000000000000000 _start: 0: 000b05b3 cma a0,a1,a2能看到cma a0,a1,a2這一行說明反匯編方向也通了。需要注意如果你看到的是.word 0x000b05b3而不是助記符先檢查MASK_CMA和MATCH_CMA這兩個(gè)宏對不對尤其是MASK。我見過有人把MASK當(dāng)成0xffffffff來寫這會(huì)導(dǎo)致rs1、rs2、rd字段也被當(dāng)作固定匹配位結(jié)果只有特定寄存器組合的指令才能被反匯編出來這是最常見的大坑。這個(gè)階段的經(jīng)驗(yàn)是匯編器和反匯編器是改起來最直觀的因?yàn)樗鼈冎恍枰次黄ヅ洳挥美斫庵噶畹恼Z義。你在這里花了工夫把表和掩碼搞對后面GCC接入時(shí)會(huì)輕松很多因?yàn)镚CC最終生成的匯編文本還是要經(jīng)過gas這一層。4. GCC適配讓C代碼能直接調(diào)新指令4.1 機(jī)器描述文件在riscv.md里描述指令語義匯編器能用只說明程序員可以在匯編層寫這條指令但對絕大多數(shù)使用者來說更希望直接在C代碼里調(diào)用。這時(shí)候就得改GCC RISC-V后端。GCC后端和binutils最大的區(qū)別是GCC要理解這條指令的語義才能參與優(yōu)化、寄存器分配、指令調(diào)度。你告訴它的方式就是機(jī)器描述文件gcc/config/riscv/riscv.md用RTL寄存器傳輸語言來描述指令做什么。我在這個(gè)文件里加的模式定義是這樣的用的是語義化描述乘法加加法而不是不可理解的unspec;; 自定義cma指令rd rs1 * rs2 rd (SI即32位) (define_insn cma_si3 [(set (match_operand:SI 0 register_operand r) (plus:SI (mult:SI (match_operand:SI 1 register_operand r) (match_operand:SI 2 register_operand r)) (match_operand:SI 3 register_operand 0)))] TARGET_XCUSTOM cma\t%0,%1,%2)這里有幾個(gè)點(diǎn)必須解釋。第一第3個(gè)操作數(shù)match_operand:SI 3對應(yīng)的約束是0意思是操作數(shù)0和操作數(shù)3必須分配到同一個(gè)寄存器這就是我們這條指令rd同時(shí)是累加器和目的寄存器的硬件約束。GCC在看到這個(gè)約束后會(huì)在寄存器分配時(shí)強(qiáng)制讓兩個(gè)操作數(shù)共用一個(gè)寄存器如果做不到它會(huì)自動(dòng)插入mov指令來滿足約束。第二我用了真正的語義mult plus而不是unspec。這兩條路各有取舍。用unspec對GCC來說是一條黑盒指令它不知道你在算什么不會(huì)瞎優(yōu)化但也沒法利用這條指令的代數(shù)性質(zhì)。用語義模式GCC就清楚這是乘加它可能會(huì)把別的乘加表達(dá)式也匹配到這個(gè)模式上優(yōu)化機(jī)會(huì)更多但風(fēng)險(xiǎn)是萬一你的硬件實(shí)現(xiàn)和標(biāo)準(zhǔn)乘法加法語義有細(xì)微差異比如溢出行為不同、飽和處理不同編譯器會(huì)認(rèn)為它和普通乘加等價(jià)從而在你不知情的地方做了不正確的變換。自定義指令如果語義和標(biāo)準(zhǔn)運(yùn)算不完全一致建議保守一點(diǎn)用unspec加UNSPEC常量如果語義就是標(biāo)準(zhǔn)乘加用語義模式更好。我這里的cma語義就是標(biāo)準(zhǔn)乘加所以用語義描述。第三TARGET_XCUSTOM是個(gè)宏在riscv.h里定義表示當(dāng)前編譯選項(xiàng)里啟用了xcustom擴(kuò)展。這塊要和下一條說GCC的-march解析掛上鉤。4.2 內(nèi)置函數(shù)從C代碼到新指令的橋梁機(jī)器描述文件定義了GCC內(nèi)部怎么看待這條指令但用戶沒法直接用。要提供C語言的可調(diào)用接口就得加內(nèi)置函數(shù)builtin function。GCC RISC-V后端的內(nèi)置函數(shù)注冊在gcc/config/riscv/riscv-builtins.cc里。新版本GCC定義內(nèi)置函數(shù)有兩種機(jī)制。一種是用__builtin_riscv_cma這種顯式內(nèi)置函數(shù)你在builtins文件里注冊函數(shù)原型和參數(shù)類型提供一個(gè)riscv_expand_builtin的擴(kuò)展邏輯讓它把函數(shù)調(diào)用展開成我們定義的cma_si3模式。簡化后的注冊邏輯大概是/* riscv-builtins.cc 中注冊cma內(nèi)置函數(shù) */ static void riscv_init_builtins_1 (void) { tree ftype build_function_type_list (void_type_node, intSI_type_node, intSI_type_node, intSI_type_node, NULL_TREE); add_builtin_function (__builtin_riscv_cma, ftype, RISCV_BUILTIN_CMA, BUILT_IN_MISC, NULL, NULL); }然后做函數(shù)展開把內(nèi)置函數(shù)的三個(gè)參數(shù)取出來轉(zhuǎn)成rtx再emit到cma_si3模式/* 展開邏輯 */ static rtx riscv_expand_cma_builtin (tree exp) { rtx dst gen_reg_rtx (SImode); rtx src1 expand_normal (CALL_EXPR_ARG (exp, 0)); rtx src2 expand_normal (CALL_EXPR_ARG (exp, 1)); rtx acc expand_normal (CALL_EXPR_ARG (exp, 2)); emit_insn (gen_cma_si3 (dst, src1, src2, acc)); return dst; }另一方面是直接讓GCC自動(dòng)猜算RISC-V后端在較新的版本里提供了一種叫自定義擴(kuò)展內(nèi)建函數(shù)的機(jī)制能根據(jù)一條匯編模板自動(dòng)生成對應(yīng)builtin。具體來說你不需要手寫展開邏輯只要在riscv-c.cc里把自定義指令的助記符聲明成可調(diào)用的內(nèi)建函數(shù)就行。但由于各個(gè)GCC版本的API差異比較大我這里不展開具體代碼更推薦的方式是先在匯編層把指令驗(yàn)證通過然后用內(nèi)聯(lián)匯編做C語言層封裝最后如果你確認(rèn)這條指令在項(xiàng)目里會(huì)被高頻使用再花時(shí)間去做正式的builtin接入。4.3 什么時(shí)候用內(nèi)聯(lián)匯編什么時(shí)候用內(nèi)置函數(shù)這一步的取舍是很多團(tuán)隊(duì)工具鏈適配早期特別糾結(jié)的問題。我直接說結(jié)論原型驗(yàn)證階段用內(nèi)聯(lián)匯編最劃算產(chǎn)品化階段內(nèi)置函數(shù)是正路。內(nèi)聯(lián)匯編的寫法非常簡單static inline int32_t cma_asm(int32_t a, int32_t b, int32_t acc) { asm volatile(cma %0, %1, %2 : r(acc) : r(a), r(b)); return acc; }你只要匯編器已經(jīng)支持這條指令這段代碼就能用。它的好處是零GCC后端改動(dòng)壞處是GCC把a(bǔ)sm volatile當(dāng)一堵墻它不知道你這段匯編做了乘加運(yùn)算沒法參與優(yōu)化而且不可避免會(huì)帶來寄存器壓力、指令調(diào)度變差這些損耗。內(nèi)置函數(shù)則讓編譯器完全理解語義可以進(jìn)行常量折疊、公共子表達(dá)式消除這些優(yōu)化。代價(jià)就是得維護(hù)GCC后端的修改后期還要跟隨GCC版本升級重新移植。對芯片公司來說這個(gè)是產(chǎn)品化的必經(jīng)之路但對一個(gè)剛開始研究RISC-V自定義擴(kuò)展的團(tuán)隊(duì)來說我建議分兩步走別一上來就啃GCC后端。另外提醒一個(gè)很多人不知道的點(diǎn)__builtin_riscv_*這類內(nèi)置函數(shù)是否能被識別還取決于GCC編譯時(shí)的-march參數(shù)。GCC里ISA開關(guān)的控制有兩層一層是riscv.opt里定義的各種-misa-spec、-march之類的選項(xiàng)解析另一層是riscv.cc里的riscv_parse_arch_string函數(shù)解析的擴(kuò)展名列表。如果你的xcustom擴(kuò)展沒有在這個(gè)解析列表里你傳-marchrv64gc_xcustom的時(shí)候GCC會(huì)直接報(bào)unknown extension。5. Spike與QEMU模擬器驗(yàn)證讓新指令真正跑起來5.1 Spike適配從編碼表到執(zhí)行函數(shù)軟件工具鏈這邊全部改完之后該跑真實(shí)執(zhí)行了。最合適的驗(yàn)證起點(diǎn)是Spike它是RISC-V官方的指令集模擬器結(jié)構(gòu)很簡單適合做ISA層面的驗(yàn)證。Spike適配需要改三個(gè)地方。第一步在riscv/encoding.h里加上指令的匹配宏和聲明#define MATCH_CMA 0x0b #define MASK_CMA 0xfe00707f DECLARE_INSN(cma, MATCH_CMA, MASK_CMA)第二步在riscv/insns/目錄下新建一個(gè)cma.h文件實(shí)現(xiàn)指令的具體模擬行為/* riscv/insns/cma.h */ { reg_t old_rd x(insn.rd()); WRITE_RD(RS1 * RS2 old_rd); }Spike的機(jī)制很直觀每個(gè)支持執(zhí)行的指令對應(yīng)一個(gè)insns/指令名.h文件文件里的代碼會(huì)被展開成一個(gè)接收當(dāng)前指令信息、讀寫寄存器堆的執(zhí)行函數(shù)。RS1、RS2分別代表rs1、rs2寄存器的當(dāng)前值WRITE_RD負(fù)責(zé)把結(jié)果寫回目標(biāo)寄存器。注意我們的指令rd既是源又是目的所以先x(insn.rd())把累加器的舊值讀出來再做乘加這個(gè)順序邏輯上要特別小心。如果你的自定義指令有訪存行為這一步還要考慮尾聲裝置tail處理不能只在寄存器里算完就完事。第三步在riscv/insn_list.h不同版本可能叫別的名字里聲明這條指令DECLARE_INSN(cma, MATCH_CMA, MASK_CMA)這個(gè)列表會(huì)被Spike的decode表生成邏輯掃一遍把每條指令的match/mask綁定到對應(yīng)的執(zhí)行函數(shù)上。改完重新編譯Spike用Spike跑我們之前的test.elfspike --isarv64gc_xcustom pk test.elf如果程序能正常跑完并退出碼正確那說明這一條指令從符號到執(zhí)行全部通了。在動(dòng)手之前可以用echo $?看看退出碼是不是和預(yù)期一致。5.2 QEMU適配decode文件與trans函數(shù)QEMU的RISC-V后端適配方式完全不同原因是它用TCG做動(dòng)態(tài)翻譯先把目標(biāo)指令翻譯成TCG中間指令再翻譯成宿主機(jī)代碼。QEMU的好處是性能比解釋型模擬器高很多跑完整軟件棧更現(xiàn)實(shí)。QEMU的RISC-V解碼機(jī)制在target/riscv/insn32.decode文件里。這是一個(gè)類Decodetree的格式描述文件我需要給cma指令加一行編碼模板# target/riscv/insn32.decode cma 0000000 ..... ..... 000 ..... 0001011 r這行格式的意思很直白前7位funct7固定0000000中間三個(gè)寄存器字段用.....表示任意5位funct3固定000最后一個(gè)7位opcode固定0001011整體是R型格式r。Decodetree生成工具會(huì)自動(dòng)生成這條指令的解碼函數(shù)把指令的rs1、rs2、rd字段提取出來放進(jìn)arg_cma結(jié)構(gòu)體里。然后實(shí)現(xiàn)翻譯函數(shù)。我新建了一個(gè)trans_cma函數(shù)放在target/riscv/insn_trans/trans_rvi.c.inc如果你有獨(dú)立的custom擴(kuò)展文件也可以單獨(dú)建一個(gè)inc文件static bool trans_cma(DisasContext *ctx, arg_cma *a) { TCGv t0 tcg_temp_new(); TCGv t1 tcg_temp_new(); tcg_gen_mul_tl(t0, cpu_gpr[a-rs1], cpu_gpr[a-rs2]); tcg_gen_add_tl(t1, cpu_gpr[a-rd], t0); tcg_gen_mov_tl(cpu_gpr[a-rd], t1); tcg_temp_free(t0); tcg_temp_free(t1); return true; }這段TCG代碼的邏輯就是t0 rs1 * rs2t1 rd t0再把結(jié)果寫回rd。TCG的臨時(shí)變量要記得釋放不然一個(gè)復(fù)雜的基本塊翻譯下來臨時(shí)變量會(huì)堆積。QEMU這邊比較容易踩坑的點(diǎn)是decodetree模板的位數(shù)和字段順序必須和編碼精確一致尤其是寄存器字段的下劃線數(shù)量。.....差一個(gè)點(diǎn)生成的解碼函數(shù)就完全不是你想要的樣子。另外QEMU對非標(biāo)準(zhǔn)擴(kuò)展的支持在不同版本里變動(dòng)很大新版QEMU8.0以上還引入了riscv,isa字符串解析、多擴(kuò)展配置這些機(jī)制如果你只在老的insn32.decode里加了一個(gè)模板有可能因?yàn)镮SA字符串里沒有激活這個(gè)擴(kuò)展而拒絕解碼。這塊要看你用的具體版本老版本直接加就行新版本需要同步在riscv_isa_ext相關(guān)的表里注冊擴(kuò)展。5.3 FPGA與真機(jī)驗(yàn)證簡述模擬器跑通之后最后一步是硬件驗(yàn)證。這部分工作量和RTL實(shí)現(xiàn)強(qiáng)相關(guān)我只從工具鏈配合角度說幾個(gè)要點(diǎn)。在FPGA上你的自定義指令一般以兩種方式存在一是直接改RTL的譯碼和執(zhí)行流水二是用一個(gè)協(xié)處理器接口掛接。無論是哪種驗(yàn)證時(shí)你都需要把軟件生成的二進(jìn)制喂給CPU核。這時(shí)候前面做的工具鏈工作就開始體現(xiàn)價(jià)值了你可以用GCC編出一段真實(shí)的業(yè)務(wù)代碼里面混著大量cma指令直接燒到FPGA上和模擬器的行為做對拍。硬件驗(yàn)證階段特別建議做一件事在RTL里加一個(gè)指令統(tǒng)計(jì)計(jì)數(shù)器對碰cma這條指令被執(zhí)行的次數(shù)和Spike或QEMU側(cè)用調(diào)試器或trace工具統(tǒng)計(jì)出來的執(zhí)行次數(shù)做比對。如果兩邊次數(shù)不一致說明有分支預(yù)測或者異常路徑上的指令執(zhí)行行為沒對齊這種問題在純軟件模擬階段根本發(fā)現(xiàn)不了。6. 常見問題與排錯(cuò)實(shí)錄6.1 匯編器報(bào)錯(cuò)unrecognized opcode這是最靠前的報(bào)錯(cuò)說明gas那條路還沒通。按順序排查第一riscv-opc.c里的數(shù)組記錄加了嗎格式對不對第二riscv-opc.h里的DECLARE_INSN有沒有第三匯編命令行里的-march有沒有帶上xcustom第四riscv_multi_subset_supports函數(shù)里有沒有對INSN_CLASS_XCUSTOM放行。我遇到過的真實(shí)情況是前三個(gè)都對但gas的ISA子集解析函數(shù)在解析xcustom時(shí)因?yàn)榇笮憜栴}沒匹配上導(dǎo)致放行失敗。RISC-V擴(kuò)展名規(guī)范里非標(biāo)準(zhǔn)擴(kuò)展必須小寫x開頭寫成XCUSTOM大概率會(huì)被拒。6.2 objdump反匯編顯示.word而不是助記符這個(gè)前面已經(jīng)提過優(yōu)先懷疑MASK寫得不對。把MASK_CMA誤設(shè)成0xffffffff是最經(jīng)典的問題這樣只有rs1、rs2、rd恰好全是0的指令才能匹配成功。你有幾條測試指令要么湊巧能反匯編出來要么就全部顯示成.word。另外注意objdump匹配指令的順序是按riscv_opcodes[]數(shù)組的先后來的數(shù)組里的記錄如果和已有的標(biāo)準(zhǔn)指令撞了match/mask標(biāo)準(zhǔn)指令會(huì)優(yōu)先匹配上。所以自定義指令的match一定要檢查是否和現(xiàn)有表重復(fù)尤其是你用funct7、funct3全0這種寬松編碼的時(shí)候。判斷依據(jù)很簡單match值相同且mask和已有指令有重疊就是沖突。6.3 GCC報(bào)unrecognizable insn這個(gè)報(bào)錯(cuò)發(fā)生在GCC后端意思是GCC生成了某個(gè)RTL模式但目標(biāo)機(jī)器描述文件里沒有能匹配的指令模板。多半是riscv.md里的模式約束寫錯(cuò)了。比如我在cma_si3模式里用了約束0讓第3個(gè)操作數(shù)和第0個(gè)操作數(shù)共用寄存器如果模式里的操作數(shù)下標(biāo)寫錯(cuò)GCC在寄存器分配階段生成不了合法的匯編就會(huì)在final階段報(bào)unrecognizable insn。排查方法是用-fdump-rtl-all把GCC的RTL中間結(jié)果打到文件里看最終那個(gè)無法識別的insn長什么樣再對照機(jī)器描述的模式和約束找差異。6.4 Spike報(bào)Illegal InstructionSpike在encoding.h和insn_list.h里都聲明了指令但運(yùn)行時(shí)報(bào)非法指令一般是decode表沒有生成。Spike的decode表在processor.cc的初始化流程里會(huì)根據(jù)insn_list構(gòu)建一個(gè)按match分組的跳轉(zhuǎn)表如果你的DECLARE_INSN宏位置不對或者指令的match值被別的指令的mask覆蓋就會(huì)匹配不到。有個(gè)快速驗(yàn)證辦法在Spike的decode函數(shù)里臨時(shí)打印當(dāng)前pc附近的原始指令編碼手動(dòng)跟MATCH_CMA比對排除編碼問題。6.5 問題排查速查表現(xiàn)象優(yōu)先排查常犯錯(cuò)誤gas報(bào)unrecognized opcodeopcode表、subset支持march忘記帶xcustom或大小寫錯(cuò)誤objdump顯示.wordMATCH/MASK宏MASK誤設(shè)為全1match與已有指令沖突GCC報(bào)unrecognizable insnriscv.md模式、約束操作數(shù)下標(biāo)寫錯(cuò)約束字符串不對Spike非法指令encoding.h、insn_listDECLARE_INSN位置不對match重復(fù)QEMU不能解碼insn32.decode模板點(diǎn)位數(shù)量不對ISA擴(kuò)展未注冊6.6 兩個(gè)值得提前做的防坑措施最后分享兩個(gè)我個(gè)人的習(xí)慣。一是每次改動(dòng)工具鏈某個(gè)組件后都用最小測試工程跑一遍匯編、反匯編、編譯、執(zhí)行四步四步全過再進(jìn)下一步。這樣做的好處是問題永遠(yuǎn)被限制在當(dāng)前改的組件里不至于改到后面還要回頭猜是哪一環(huán)壞了。二是給自己的每條自定義指令寫一張編碼定義表放在倉庫里和RTL代碼、工具鏈代碼一起追版本。包括指令助記符、功能語義、位域分配、MATCH/MASK、寄存器和立即數(shù)格式?？雌饋碇皇且粡埍淼?dāng)年你加到第20條、第50條自定義指令的時(shí)候會(huì)發(fā)現(xiàn)這張表是救命稻草它能幫你防止編碼沖突、幫助新同事快速上手也能在工具鏈和RTL對不上時(shí)快速定位分歧。我個(gè)人跑完這趟流程最大的體會(huì)是RISC-V自定義擴(kuò)展的核心工作量其實(shí)不在RTL實(shí)現(xiàn)而在軟件工具鏈的方方面面。每條指令都要過匯編、反匯編、編譯、模擬器、硬件驗(yàn)證五關(guān)每一關(guān)的報(bào)錯(cuò)方式都不同排錯(cuò)思路也完全不同。但一旦你用上面的流程把第一個(gè)簡單指令跑通后面再加新指令就只是重復(fù)勞動(dòng)基本不會(huì)再卡殼了。如果你正準(zhǔn)備動(dòng)手我的建議是先挑一條最簡單的R型算術(shù)指令用今天這套流程完整走一遍模擬器和FPGA上都跑通再去做那些帶立即數(shù)、帶訪存、帶條件執(zhí)行的復(fù)雜指令會(huì)順暢得多。