RISC-V 双周简报 (2018-06-22)

要点新闻：

• RISC-V Day Shanghai即将举行，纪念版T恤不容错过
• 第二轮 RISC-V Day 2018 Shanghai学生参会资助计划开启

RV新闻

RISC-V Day 2018 Shanghai

RISC-V Day 2018 Shanghai将会是本年度唯一由基金会在中国大陆举办的研讨会，会议的议程已经公布。(URL: https://tmt.knect365.com/risc-v-day-shanghai/agenda/1)

这次为期一天的研讨会汇集了大大小小一共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的机会。

资助计划详细内容如下

在校学生需要使用教育邮箱发送资助申请信到邮箱 xfguo@xfguo.org

学生需要首先简单介绍自己，尤其是学术经历和项目经历，之后我们很想了解你为什么对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修复了这个问题

Link: RISC-V SW Dev 上的讨论

编辑整理：汪平

为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。

Link: sw-dev 上的讨论

编辑整理：黄玮

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年。

Link: isa-dev上的讨论

编辑整理：宋威

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的映射并不唯一。

Link: isa-dev上的讨论

编辑整理：宋威

安全点评

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:

• isa-dev上的讨论
• Intel Lazy FPU Save/Restore
• privileged spec

编辑整理：林容威

实用资料

交叉编译工具链的命名

可能会看到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:

• The RISC-V Embedded GCC
• 交叉编译工具链命名详解

编辑整理：汪平

行业视角

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: 雷锋网报道

暴走事件

六月

• RISC-V Day Shanghai, 2018年6月30日 https://tmt.knect365.com/risc-v-day-shanghai/
• 2018年7月1日下午，也就是RISC-V Day Shanghai的后一天会有HelloLLVM的线下聚会活动，地点在张江高科地铁站附近的传奇广场的Vπ咖啡，何不一波流来上海玩一把？
• 2018年6月25日至27日，DAC 2018将会大量的RISC-V专题演讲 基金会页面

七月

• RISC-V Workshop in Chennai (July 18-19)

十月

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

十二月

• RISC-V Summit in Santa Clara (Dec. 3-5)

招聘简讯

CNRV提供为行业公司提供公益性质的一句话的招聘信息发布，若有任何体系结构、IC设计、软件开发的招聘信息，欢迎联系我们！

整理编集: 宋威、黄柏玮、汪平、林容威、傅炜、巍巍、郭雄飞、黄玮

欢迎关注微信公众号CNRV，接收最新最时尚的RISC-V讯息！

本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。