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

要點新聞：

• RISC-V Day Shanghai即將舉行，紀念版T恤不容錯過
• 第二輪 RISC-V Day 2018 Shanghai學生參會資助計劃開啟

RV新聞

RISC-V Day 2018 Shanghai

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

群頭為這次活動設計了紀念版T恤，因為生產需要時間所以數量有限，現場會按照註冊時間的先後順序發放！距離會議召開還有不到一週時間，請不要錯過!

編輯：雄飛

社群活動

第二輪 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月29日23點截止，所有的資助將於會議結束之後發放！

我們將會綜合評定以後決定資助誰和資助多少費用。

一些說明：

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

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

根據第一輪資助得到的反饋，請注意以下事項：

• 確保你提供的微訊號可以被別人新增，也請隨時注意是否有人加你微信（否則我們想給你錢都給不了）
• 請注意這是一個非官方的活動，並非完全由基金會發起
• 因為這是一個非官方的資助，所以請按照正常流程註冊活動！也就是說，得到資助並不意味著不需要註冊！

PS:第一波我們一共接收到了35個申請並且全部給予了補貼！

編輯：雄飛

技術討論

LLVM的RISC-V後端實現中__builtin_eh_return函式的返回值錯誤

I’m trying to add exception handling support to the LLVM’s RISC-V backend, to be able to properly support D’s runtime and standard libraries, but I’ve run into a puzzling behavior of libgcc’s _Unwind_RaiseException. When a D program throws an exception, the D runtime calls _Unwind_RaiseException. Instead of calling the D exception handling personality, _Unwind_RaiseException returns a meaningless value.

Luís Marques想在LLVM的後端實現中新增一個異常處理控制代碼來實現對D語執行時和標準庫的支援，但在執行程式時遇到一個libgcc的_Unwind_RaiseException令人迷惑的行為。當D語言程式丟擲異常時，D語言執行時會去呼叫_Unwind_RaiseException。 而手工去呼叫D的異常控制代碼時，_Unwind_RaiseException會返回一個沒有意義的值。

Jim Wilson發現是函式__builtin_eh_return返回值被破壞了。 具體細節：

I traced the problem to the implementation of the __builtin_eh_return function in the RISC-V backend. The code was copied from the MIPS port. It is using the first four arg registers for EH data, and then saving them in the prologue and restoring them in the epilogue. The MIPS port however has separate function return value regs from the argument registers, so it works. In the RISC-V port, the function return value regs overlap the argument regs, so this is clobbering the function return value in the epilogue, which is the problem you noticed.

追蹤這個問題時發現__builtin_eh_return函式的程式碼是從是MIPS的實現中拷貝過來的.__builtin_eh_return函式用靠前的四個引數暫存器儲存和恢復EH資料. 然而在MIPS實現中把引數暫存器和值暫存器做了區分，所以能正常工作，而在RISC-V中，返回值暫存器和引數暫存器是公用的，這樣就破壞了返回值，所以引起了Luís Marques注意到的問題。

最終經過Luís Marques和Jim Wilson的討論，patch，測試，通過patch gcc修復了這個問題

編輯整理：汪平

為GNU編譯器定義通用LP/SP（或者LX/SX）偽指令（RISC-V C API Documentation）

Palmer Dabbelt在sw-dev的郵件組提到他正在起草一個RISC-V C語言API文件。這個文件的目的是記錄和維護各個RISC-V編譯器（GCC，LLVM和其他商業編譯器）的C語言API以方便查詢。

這個討論被Michael Clark轉到了另外一個相關話題：為GNU Assembler (gas）編譯器定義通用LP/SP（或者LX/SX）偽指令。在現有的的RISC-V彙編裡，RV32模式使用LW指令從記憶體讀取32位內容到暫存器（或者使用SW指令儲存32位暫存器內容到記憶體）；在RV64模式下，相應的指令變成LD/SD指令（64位）。由於缺乏通用的偽指令，造成使用者必須為RV32和RV64編寫不同的彙編程式碼，非常的麻煩。Michael的提議是定義LP/SP（或者LX/SX）通用偽指令，這些指令在RV32下被編譯器自動擴充套件成LW/SW；相應的，在RV64模式下被擴充套件成LD/SD。

這個提議得到Liviu Ionescu等人的大力響應，最後討論的結果是使用LW/SX作為偽指令的命名。Jim Wilson會寫一個patch來支援這個新功能。Palmer Dabbelt同時提議，應該加入如下的類似的功能：

• 為浮點運算定義LF/SF指令：基於有無雙精度浮點擴充套件（D Extension），這些指令被自動切換成FLW/FSW或者FLD/FSD。
• 為指標定義LP/SP指令：基於ilp32或者lp64呼叫約定(calling convention)，這些指令被自動切換成LW/SW或者LD/SD。

編輯整理：黃瑋

RISC-V如何支援big-endianness

最近有一位日本學者在郵件列表上詢問，RISC-V如何能支援big-endianness，如果現在還沒有支援，支援big-endianness有多困難？結果，這個問題引出了一連串關於little/big-endianness的討論。

首先，令小編吃驚的是，在日本，儘管99%的移動端、手機、多媒體、資料中心都使用little-endian模式，90%的工業和基礎設施的應用都使用big-endian模式，比如說子彈頭火車的控制、省級鐵路系統、核電站控制等等。日本政府和日立想使用RISC-V處理器來替代現有的PowerPC, SH, 68K和Coldfire處理器，但是支援big-endian顯然成為了一個關鍵問題。

RISC-V原有的B指令集擴充套件本來是有支援little/big-endian資料轉換指令的。但是隨著B擴充套件指令集工作小組的解散，何時RISC-V能支援little/big-endian資料轉換指令還不得而知。有人提出，我們為何不定義專門為big-endian資料訪問的指令呢。儘管這樣的指令擴充套件會帶來一定的效能提升，但是遭到了Ron Minnich (Google/Coreboot)和Andrew Waterman (SiFive)的極力反對。通過雙方的多輪討論，最後得出的意見大概是：

• 如果更聰明地寫程式碼，程式碼是可以寫成endianness不敏感的，這樣就不存在big-endian移植的問題。
• 實際生活中的程式並不是完美的程式碼，所以可能存在大量需要移植的程式碼，但是移植也只是需要資料轉換指令，更多地big-endian指令其實沒有實際作用。大部分的商用指令集也都只支援資料轉換指令。
• RISC-V的指令集空間現在已經比較緊張，不太可能為big-endian去新增專門的big-endian資料讀取指令，但是資料轉換指令是一定會被加上的。
• 實際上，大部分的指令集都已經預設little-endian，儘管它們可能一開始是預設big-endian的。從ARMv7之後，ARM已經拋棄了little/big-endian雙模的支援。
• 依賴編譯器去直接編譯big-endian程式碼到little-endian處理器執行是非常困難的。當年Intel ICC編譯器為了支援Cisco big-endian程式的自動編譯，一隊工程師花了整整5年。

編輯整理：宋威

RVC到RV指令的擴充套件並非唯一

RISC-V的壓縮指令集擴充套件RVC在定義時，規定每一條RVC指令都必須能等價翻譯成一條RISC-V標準指令。最近，Luke K. C. Leighton提問，為什麼C.MV r0, rs2被翻譯成add r0, x0, rs2而不是addi, r0, rs2, 0。後者是標準指令集中對應的MV指令。也就是說，C.MV和MV被擴充套件成了不同的指令。針對這個問題，Andrew回答，其實RVC指令到RV指令並不是唯一確定的，處理器實現可以根據自己的需要選擇指令。對應的RISC-V標準中對應RVC擴充套件的描述過於狹隘了，應該需要明確指出RVC到RV的對映並不唯一。

編輯整理：宋威

安全點評

Intel Lazy FPU Save/Restore 漏洞是否影響 RISC-V

lkcl 在郵件列表裡提到，英特爾晶片曝出延遲儲存/恢復浮點狀態的方式存在漏洞。浮點運算部件（FPU）在切換任務時儲存、恢復狀態的方式，尤其是延遲恢復 FPU 的策略存在漏洞，是另一種推測執行漏洞。

lkcl 想了解下 RISC-V 的實現對於這種在上下文切換中延遲儲存/恢復狀態的方式是否也可能存在問題。

Jacob Lifshay 認為英特爾的這個漏洞不在於過度優化，而是推測執行了所有的東西（儘管有些是沒有必要的）。

Brady O’Brien 提到特權規範（privileged spec）裡是支援 FPU 延遲進行上下文切換的，在 mstatus 暫存器裡的 FS 和 XS 欄位。規範裡有提到， FS 欄位的定義裡沒有禁止當推測錯誤時把 FS 欄位設定為髒位（dirty），但是具體的實現可以選擇禁止推測地寫 FS 欄位，從而消除潛在的側通道攻擊風險。

Alex Elsayed 也認為該漏洞跟延遲上下文切換無關，這是一種 Spectre 型別的攻擊方式，可以洩漏已經禁用的功能部件和暫存器組（Regfile File）的資訊。

Link:

編輯整理：林容威

實用資料

交叉編譯工具鏈的命名

可能會看到riscv64-unknown-elf-gcc和riscv32-none-elf-gcc這樣的編譯器名或者類似命名的編譯工具鏈名，那麼這些名字是怎麼來的呢？區別是什麼呢?

交叉編譯工具已經形成了一個統一的命名規則: <arch>-<vendor>-<os>-<libc/abi>, 其中各部分含義:

• arch – 體系架構，如ARM，MIPS，RISC-V
• vendor – 工具鏈提供商
• os – 目標作業系統
• abi – libc或者應用二進位制介面（Application Binary Interface）

具體解釋:

• arch 體系架構: 表示交叉編譯器，是用於哪個目標系統架構中，用於那個平臺中, 也就是說用此交叉編譯器編譯出來的程式，是執行在哪種CPU上面如MIPS，RISC-V, 對於RISC-V還分riscv64, riscv32

• vendor 編譯鏈提供商: 表示誰提供的，即誰製作出來這個交叉編譯器的。vendor的值，貌似是可以自己隨便填寫的。 但常見的是寫成編譯交叉編譯器的作者的自己的名字的。比如，我叫abc，那麼就可以寫成abc，然後生成的交叉編譯器， 就是xxx-abc-xxx-xxx了。

• os 作業系統

  • 其實指的是，你用此交叉編譯器，編譯出來的程式，所執行的目標系統。即此交叉編譯器，編譯出來的程式，在什麼系統中，什麼環境中，執行。
  • 如果是Linux, 表示用此交叉編譯器編譯出來的程式，是要運行於帶Linux作業系統環境中的
  • 如果是bare-metal，表示用此交叉編譯器去編譯一個程式是執行在無作業系統的裸板上的.所以這種情況下不支援那些跟作業系統關係密切的函式，比如fork

• abi 應用二進位制介面: ABI，application binary interface (ABI)，應用程式二進位制介面是為了應用程式與作業系統之間，應用程式和其用到的庫之間，應用程式各個元件之間二進位制級別的相容，允許編譯好的目的碼在使用相容ABI的系統中無需改動就能執行。

而RISC-V也遵循了GCC的推薦的命名方法, 使用<arch>-<vendor>-<os>-<libc/abi>格式對於有linux作業系統使用riscv64-unknown-linux-gnu- and riscv32-unknown-linux-gnu-對於沒有作業系統的裸機程式使用riscv64-unknown-elf- and riscv32-unknown-elf-.

但不幸的是，riscv64和riscv32可能會引起混淆，因為riscv64和riscv32的64和32並不意味著工具本身只能在64或者32位執行，也不是指工具編譯出的二進位制程式在64位的riscv平臺執行或者在32位riscv平臺執行. 事實上能編譯出32或者64位的程式，由-march和-mabi決定. 這兩種寫法唯一的區別是在沒有指定命令列引數-march和-mabi時的預設值不同。

為了較少混淆，和riscv64-unknown-linux-gnu區分， GNU MCU Eclipse RISC-V Embedded GCC從 7.2.0-1-20171109 release版本以後的，通過libgloss實現了核心陷阱的gcc採用了riscv-none-embed 命名.

riscv-none-embed更適合用來生成嵌入式裸機程式

引數-march和-mabi解釋, 請參看link中的"-march and -mabi"章節和"Multiple libraries"章節

Links:

編輯整理：汪平

行業視角

OURS譚章熹：就算不替代Arm，RISC-V架構AI晶片無疑也是IoT時代的重要玩家

雷鋒網最近的文章採訪了OURS的Founder譚章熹。OURS（Optical Universal RISC Systems），一家位於美國矽谷的AI晶片初創公司，由兩位具有技術背景的華人在2017年聯合創立，手握多個好技術選擇優先把RISC-V架構晶片和矽光技術完全產業化。

在採訪中譚章熹提到了他對RISC-V的一些看法：

架構即為OURS技術優勢之一，OURS採用的RISC-V是RISC（Reduced Instruction Set Computing，精簡指令集）的第五代版本，出自 2017 年兩位新晉圖靈獎得主 John L. Hennessy 和 David Patterson之手，由加州大學伯克利分校於1980年釋出。譚章熹表示，選擇RISC-V並不是因為我是Patterson的學生，而是技術和市場需求所決定。**智聯網的需求是高定製化、高模組化、可擴充套件化以及支援新的技術，而Arm架構不允許加入新的東西，也不允許定製化和修改，並且還有專利授權費。**相反，技術上看，RISC-V 相比Arm架構處理器功耗低 5-6倍、面積效率提升5倍，可以讓開發者有很多的自由度做一些特殊應用的優化，商業上看，RISC-V開源沒有專利授權費用，對創業公司非常友好，大大降低了資金門檻。除此之外，我也是離RISC-V最近的人，因此無論從哪個角度看，RISC-V都是OURS最好的選擇。RISC-V也是能和Arm媲美和競爭的架構，即使在IoT領域不替代Arm，RISC-V也將成為非常重要的玩家。

Link: 雷鋒網報道

暴走事件

六月

• 2018年7月1日下午，也就是RISC-V Day Shanghai的後一天會有HelloLLVM的線下聚會活動，地點在張江高科地鐵站附近的傳奇廣場的Vπ咖啡，何不一波流來上海玩一把？
• 2018年6月25日至27日，DAC 2018將會大量的RISC-V專題演講 基金會頁面

七月

十月

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

十二月

招聘簡訊

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

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

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