RISC-V 雙週簡報 (2018-06-08)

要點新聞：

• RISC-V Day 2018 Shanghai研討會議程公佈
• RISC-V Day 2018 Shanghai學生參會資助計劃

RV新聞

RISC-V Day 2018 Shanghai研討會議程公佈

這次為期一天的研討會彙集了一共15個演講。上午的議程主要集中展示商業和開源的RISC-V CPU IP，分別來自AndesTech、SiFive、Syntacore、Codasip和來自國內的蜂鳥；而下午的議程則討論處理器架構研究、處理器安全和的生態系統等話題。相比技術話題，或許能夠認識更多業內的朋友對參會者來說更有價值。

早鳥票將於6月17日截止。我們同時也發起了非官方的支援學生參會的資助計劃，參見下一篇報道。

社群活動

RISC-V Day 2018 Shanghai學生參會資助計劃

RISC-V Day 2018 Shanghai將在6月30日在復旦大學光華樓吳文政報告廳舉辦，RISC-V正被國內越來越多的高校學生所接觸和學習。相比x86、ARM和MIPS，我們相信因為RISC-V標準本身的開放，以及建立在這種開放之上的大量開源專案，能夠讓學術研究更加方便和高效。

我們在此發起一個非官方的面向學生的參會資助活動，盡我們所能來幫助學生參加這次會議，給更多對RISC-V感興趣的同學一個深入瞭解RISC-V的機會。

資助計劃詳細內容如下

學生需要首先簡單介紹自己，尤其是學術經歷和專案經歷，之後我們很想了解你為什麼對RISC-V感興趣，並且願意付出時間來參加這次會議。如果有接觸過RISC-V甚至是做過任何相關專案，那麼我們非常想聽聽你的相關經歷和故事。（沒有也沒關係，這不會成為決定我們是否資助的關鍵因素）

請務必註明提供以下資訊：

• 真實姓名
• 所在學校、專業和年級
• 微訊號
• 手機

務必提供以下格式的郵件標題: “我想參加RISC-V Day Shanghai - 姓名 - 微訊號“

第一波申請將於6月15日晚12點截止（因為6月17日是早鳥票結束的時間）

我們將會綜合評定以後決定資助誰和資助多少費用，被資助的同學將會至少得到註冊費用(20美元)的資助，如果資金充裕，對於外地同學我們也可能會提供部分路費和住宿費用的補貼。

一些說明：

• 沒有教育郵箱的還沒上大學的學生請可以使用非教育郵箱（我知道有這樣高手的存在）
• 我們可能會要求學生提供註冊的Invoice或者車票

在此我先替你們感謝提供資助的大佬們！

技術討論

使用RVC指令導致32位元RV指令跨快取塊邊界

如果使用RVC指令，所有指令將按16位元對齊，而非32位元。那麼，就有可能出現一條32位元的正常指令橫跨兩個快取塊。對於深流水線的高效能處理器來說這並不是一個問題，因為指令快取會預先讀取快取塊，補償快取缺失導致的指令讀取延時。但是對於嵌入式處理器來說，這就有可能造成一部分的效能下降。

於是，Sean提出，我們是否可以讓編譯器在發生32位元指令未對齊時自動插入一條RVC的NOP指令呢？

問題的答案看起來並不簡單。RISC-V的RVC指令是和32位元指令一一對應的，因而連結器在目標檔案連結時也能使用RVC替換。可是連結時才知道那些指令被替換成RVC指令已經太遲了。連結器只能通過RVC替換來減小程式碼尺寸，不能增加程式碼尺寸。如果要插入NOP來確保32位元指令的32位元對齊，則需要關閉連結時的RVC優化，這樣會導致程式碼密度降低，和嵌入式處理器的一般要求相違背。

同時，也有人很細心的指出，這個問題在引入48位元指令時一定會出現。另外，MIPS最近提出的nanoMIPS指令集，通過同時使用16/32/48位元指令來壓縮32位元指令獲得了較好的壓縮效果。可見只是一味地減少指令長度能獲得最佳的程式碼密度。

編譯器的自動引數選擇

一般來說我們認為給編譯器更高的優化引數會得到更高的執行效能。但是在當前複雜的作業系統和處理器的情況下，事情並不那麼簡單。為了解決最優編譯器引數自動選取問題，GCC的開發者們開發出了一套能自動選取編譯器引數的選取引擎(CK: Collective Knowledge)：一個用Python編寫的，相容的、可移植和擴充套件的開源計算機系統研究框架。現在該框架已經支援GCC和LLVM。

中斷用例

Liviu Ionescu 寫了一篇文件詳細講述最常用的處理中斷的情形，包括用於外設和上下文切換，並根據當前的 RISC-V 規範舉了例子。

對於當前 RISC-V POSIX ABI，Liviu Ionescu 列舉了處理中斷的流程的例子：

1. 首先處理最高優先順序的中斷：
   • 進入中斷處理程式
   • 儲存 16 個通用暫存器和 20 個浮點暫存器的內容到棧裡
   • 呼叫 C/C++ 函式然後返回
   • 從棧裡恢復 16 個通用暫存器和 20 個浮點暫存器的內容
   • 退出中斷處理程式
2. 如果還有其他優先順序比較低或者一樣的中斷，每個中斷都得重複一遍上面的步驟（N 箇中斷執行 N 次）
3. 如果需要切換上下文，還得：
   • 進入裸的（naked）中斷程式
   • 儲存 32 個通用暫存器和 32 個浮點暫存器
   • 儲存棧指標到當前的執行緒控制塊
   • 選擇下一個執行緒去執行
   • 恢復 32 個通用暫存器和 32 個浮點暫存器
   • 退出裸的（naked）中斷程式

頻繁地儲存大量暫存器使得中斷處理程式變得很慢，Liviu Ionescu 的建議是：

1. 保留用於存放浮點暫存器的空間，但先不要馬上儲存這些暫存器的值，直到第一條浮點指令將被執行
2. 把 ABI 規定由呼叫函式的程式（caller）儲存的暫存器的值存到棧中
3. 呼叫用於處理高優先順序的中斷程式
4. 當在中斷模式中如果需要，還會去呼叫其他中斷程式去處理更低或者相同的中斷
5. 呼叫切換上下文（context_switch)處理程式（也許優先順序最低）
   • 儲存剩下的通用暫存器（ABI 規定由被呼叫的函式（callee）負責儲存的）
   • 儲存棧指標到當前的執行緒控制塊
   • 選擇下一個執行緒去執行
   • 從新的執行緒控制塊恢復棧指標
   • 恢復剩下的通用暫存器（ABI 規定由被呼叫的函式（callee）負責儲存的）
   • 返回
6. 從棧中恢復 ABI 規定由呼叫函式的程式（caller）儲存的暫存器的值
7. 從新的執行緒上下文中的中斷裡返回

Links:

偽指令 載入地址(la) 與 載入本地地址(lla) (la vs lla)

Michael Clark 試圖弄清如何處理重定向相關的偽指令，但是沒有在指令集文件中找到相關內容的說明：

LA         載入地址
LLA        載入本地地址
LA.TLS.GD  載入地址， 本執行緒，全域性動態載入（thread-local, global-dynamic）
LA.TLS.IE  載入地址， 本執行緒，執行時初始化 （thread-local, initial-exec）
LI         載入立即數
* 注：global-dynamic 和 initial-exec 是 GCC 執行緒私有變數型別請參閱相關文件

所以他提出問題：是不是任何字大小偏移量的重定向（word size relocation）都可能有兩個入口，一個由高20位確定，另一個由低12位確定？

Michael Clark提供了部分虛擬碼的擴充套件的工作成果，但還未完善，可能最終需要反編譯一些目標檔案來弄清楚。

Stefan O’Rear: 支援通過反編譯獲得資訊並記錄下來，提醒是不是忽略了 TAIL 和 CALL？

Nicolás Ojeda Bär : 提示 RISC-V 標準的第21章有相應的虛擬碼範例，雖然不夠詳實，但也對他編寫 OCaml 本地編譯器的後端起到了幫助。

Michael Clark已經通讀了這些虛擬碼，但是他現在對於那些還沒有在標準中列出的虛擬碼比較感興趣。這些還沒記錄在案的虛擬碼似乎都和執行緒本地的儲存和定址有關（LA, LLA）。他維護了一個元資料和約束表用於虛擬碼的轉換，但是還沒有發現一個方法來表達以上這些虛擬碼的元資料。這個 REPO 裡面的重定向部分並不準確，可以看作是他的工作筆記：https://github.com/michaeljclark/riscv-meta/blob/master/pseudos

Sebastian Huber : lla 虛擬碼由 GCC 提出，但還沒有被寫入 RISC-V 指令集手冊第一卷 ： 使用者級指令集體系結構 2.2版中。

Tommy Murphy 表示可能應該提交這個遺漏到 RISC-V 指令集手冊的 REPO 中。

Jim Wilson 表示彙編器文件可能可以用上一些 Micheal 的成果，但是很難找到志願者做這些工作。lla 已經被提及過，lla 實際上是 載入本地地址的意思，它可以擴充套件為 auipc/addi，此時 auipc 獲取地址的高位，而 addi 則獲取地址的低位。 la 是載入地址的意思，它可以在 PIC 模式下，擴充套件為 auipc/l[wd]，在非 PIC 模式下和 lla 一樣擴充套件為 auipc/addi。

棧填充方向問題 (RFC: RISC-V microcontroller profile – About the direction of filling stack)

Iztok Jeras 在 RFC: RISC-V microcontroller profile 的thread上提出: 他注意到，在RISC-V上棧的填充和讀取方向都是自頂向下的，這樣在那些訪問連續記憶體地址更高效的系統中可能會影響其效能。在大多數複雜系統中（通過記憶體突發訪問的模式）訪問連續記憶體地址會比隨機的訪問有更好的效能。

一般來說，地址預設都是增長的而不是減小。

在大型系統中，資料快取通過提供隨機的記憶體訪問隱藏了這種硬體優化，而嵌入式系統則可能沒有這樣的機制。

在這個帖子中他解釋了 SRAM 的流水線式訪問如何加速嵌入式系統的執行。

他謙虛地表示雖然自己可能對棧楨理解並不透徹，但是如果棧楨一旦確定就會被廣泛使用。當然這可能也涉及到後向相容的問題。

所以他提出問題：現在沒有可能反轉棧的訪問順序？

Jim Wilson 表示：人們應使用正式的棧回退資訊而不是從頭到尾地假定指令的順序。所以這似乎並不太可能破壞任何關鍵性的東西。由於最近較忙無瑕他顧，遂建議在 github 上開一個 issue 備案。如果 Iztok 想自己嘗試一下，可以看看 gcc/config/riscv/riscv.c. 中的 ‘riscv_for_each_saved_reg’ 函式。 建議為這個新主題開一個新的thread。

Jacob Lifshay 提出 C 擴充套件是為自頂向下的生長的棧設計的，因為推棧和出戰指令相對棧指標有一個 ‘zero-extended’ 偏移，遂無法訪問小於棧指標的地址。Jim Wilson 認為 Jacob 可能誤會了 Iztok 的意圖， Iztok 並不是向改變棧的生長方向，他只是想是否可以改變暫存器的推棧順序，比如從

sw ra,60(sp)
sw t0,56(sp)
sw t1,52(sp)
sw t2,48(sp)

變成

sw t2,48(sp)
sw t1,52(sp)
sw t0,56(sp)
sw ra,60(sp)

安全點評

構建可信鏈條對隱私有需求的個人裝置以及高安全性的雲環境一直是重要的議題，傳統Root of Trust構建基本上由verifiedboot以及measuredboot完成（參見hardenedboot)，隨著Intel SGX以及ARM平臺TEE的推廣，雖然當前雲環境中主要的需求attestation並不需要secure enclave來實現，但這並不阻礙secure enclave被業界越來越關注。

同時，MIT和UC Berkeley合作開發了另外一個叫Keystone的專案，Keystone在Sanctum的基礎上使用了PMP(類似PaX UDEREF)以增強本身的安全性，不論是Sanctum還是Keystone都是開放的設計和實現，也就意味著任何人都可以去審計後門和漏洞，這一點和Intel SGX的複雜且封閉的設計和實現完全不同。

暴走事件

六月

• 2018年7月1日下午，也就是RISC-V Day Shanghai的後一天會有HelloLLVM的線下聚會活動，地點在張江高科地鐵站附近的傳奇廣場的Vπ咖啡，何不一波流來上海玩一把？

七月

十月

• RISC-V Day Tokyo (mid-October TBD)

十二月

招聘簡訊

CNRV提供為行業公司提供公益性質的一句話的招聘資訊釋出，若有任何體系結構、IC設計、軟體開發的招聘資訊，歡迎聯絡我們！

整理編集: 宋威、黃柏瑋、汪平、林容威、傅煒、巍巍、郭雄飛、Shawn

歡迎關注微信公眾號CNRV，接收最新最時尚的RISC-V訊息！