RISC-V 通用处理器，未来在哪呢

前言

相信大家也看到了，RISC-V 通用处理器生态圈的现状并不太平。

它市场竞争力低吗？确实！
我们能改变吗？我相信还有机会！

注：本文仅代表本人立场与观点，不代表任何组织、开源社区。

现状是什么样呢？

• 基础的 Linux 内核、发行版以及大量的开源软件支持
• QEMU 级别单核性能的现存硬件
• 碎片化的 ISA 遇上想建立新纪元的发行版
• 满足 Bug-free && 快 的硬件几乎找不到
• 吵架时间过长的社区

过去几年我们经历了什么？

• ISA: RV64GC-> RV64GC_Zba_Zbb -> RVA22U64 + V + Zvfh -> RVA23U64
• CPU性能指标： CoreMark / Dhrystone -> SPECCPU
• Server Feature：Hypervisor、IOMMU、AIA

嗯，是好事，很大程度弥补了做一个通用核与 aarch64 以及 x86 的差距。

冰山之下还藏着什么？

RVA23U64 这样的标准应该是一个良好的开始，但对比现在的 aarch64 与 x86 ，我认为还远远不够。而有许多真实的，SPECCPU 跑分反映不出来的问题，却被忽视了太多太多！

ISA 本身的设计

• RVV 需要太多 additional 的预测与Rename
• RVC 让宽前端不好做，也失去了一些拆分指令前搞事的可能性
• 实际的硬件可能实现了下一代 RVA Profile 的子集但不完全兼容，软件需要 handle 碎片化才能有良好的性能。
  • 不妨看看我的 rv64.zip，真希望有人一起来构建包括但不仅限于 RISC-V 的 Universal Binary 生态！它真的可以做的又自动化，又小，又快，甚至比 ISA 扩展开全更小更快！
• 太多太多能在特定 workload 让编译器不好优化的小问题，我的博客就有 2 篇分析！
  • How CCMP reduce the pressure of branch predictor on aarch64
  • “Short-leg” of RISC-V

JIT

如果你在像 SG2042 这样的 超多核 RISC-V CPU 上 Profiling 过 JIT 应用（如Box64、Java、v8），你一定对 RISC-V 目前 I-D Cache 同步操作只有 fence.i 有巨大的意见，惊叹它怎么可以这么慢！

而现在的 Server Workload，又恰好对 JIT 以及频繁的进程启动（比如FaaS）相当敏感。

fence.i 的问题：只能做当前核的 I-Cache 全部清空来维持同步。

所以，当 OS 下的一个 JIT 用户进程刚修改完指令希望 I-Cache 同步，需要怎么做呢：

1. 给内核发一个 syscall
2. 内核通过核间中断通知所有核心执行 fence.i （也可以通过 SBI Remote fence，whatever）
3. 核心清空非一致性的 I-Cache

把 JIT 里频繁的 Cache 修改变成了一个牵一发动全核的事情。即使硬件做了 I-D 一致性，将 fence.i 仅实现为刷流水线，但若缺乏一个 Probe 其存在的标准让软件得适配，依然需要全核 IPI ，让我们一起执行 fence.i 。

反观别的主流 ISA 怎么做呢：

• x86：自带I-D一致性， Intel 手册推荐执行任意一条能刷新流水线的指令（如CPUID）即可保证写入的指令马上可用。
• aarch64：拿到修改的虚拟地址，执行 dc cvau 刷走 D-Cache，再执行 dsb ish作为 fence ，再通过 ic ivau 全核广播 I-Cache Invalidate，再执行 dsb ish 作为 fence，即可完成。

aarch64 的做法虽然看似麻烦，但实现了细粒度刷 Cache Line ，不依赖 syscall ，全程不依赖软件 IPI。甚至用虚拟地址避免了软件手动查页表的麻烦，因为刚修改完的指令一定在当前进程页表是有映射的。

而 RISC-V 这边未来的做法是啥呢：我们加一个扩展来 Probe 硬件存在 I-D 一致性：Ziccid。2025年快过了，至今还没 Ratify。等到 Ratify 了，能被 Linux Kernel hwprobe 收入，能被软件 probe 从而省掉 syscall ，又是很长很长的时间。而且至今仍然没有像 aarch64 这样对于小核足够友好的 va invalidate + bus snoop 指令。

安全特性

可能大家不知道的是，现在的消费级电子产品都越来越多部署了像 Memory Tagging 这样的软硬件协同的内存安全技术，通过很小的硬件面积避免了软件插桩做 Address Sanitizer 这样的事情的开销。Apple 更是全生态安全的代表，早早地在自家的设备上部署了相当多软硬件协同的安全技术，比如 PAC、PPL、MTE。

我认为对于软件完整性保护，从而保护个人隐私非常有利，毕竟你也不希望你的手机后台静默地收一封邮件就被攻击者打穿 Kernel 这样的事情发生吧。如果你对这段话毫无感触，可以找一些了解安全漏洞在黑市上价值的朋友聊一聊天，他们也许会告诉你那些未被公开且未被修复的各种漏洞有多么可怕。可千万不能假定每一个会挖漏洞的人都是会提交给上游让全世界一起安全的大好人。也许依然有漏网之鱼，但提高攻击者的成本，在不影响性能的情况下尽可能减小潜在的攻击面，对于安全总归是好事情。

RISC-V 这边呢？很多扩展还处在正在推（例如 RISC-V Memory Tagging），刚 Ratify 的阶段 （例如 RISC-V CFI），等到硬件实现，软件实现达到目前 x86、aarch64 类似的水平，也是需要很长很长的时间。

开源的发展机遇

真正的开源项目，绝不是一个小团队内部交流，把代码公开放在网上。是从一个小项目走出，有一群需要它的人、组织、企业一起完善它，最终凝聚了各个贡献者的知识，构建了一个足够强大的社区，日益繁荣，用户也随之受益。

而我自己，也时常在使用开源项目期间，发现许多可以改进的点，可以是自己撞到的 Bug Fixes，也可以是自己需要的新 Feature，又或是小小的性能改进，也可以是把自己发论文的项目的一部分走向现实的贡献。

我很感激这些现有的开源项目，它让我不再需要面对专有软件的黑盒，遇到问题自己修，需要 feature 自己加，性能不够好还可以用自己的多方面知识自己优化。让我不再只有打不开的，被企业垄断还只能被企业当作纯用户的黑盒子，不仅让自己有了好用的东西，还能将自己好的想法贡献给全世界一起享用。

相比之下，我真的给 Apple 写过超级多的 Feature 相关的 Feedback，包括一个 XNU 的网络栈纯纯对用户透明的优化，属于是如果是开源软件我会直接贡献的东西，然而从来没有得到任何联系和回复。虽然 XNU Kernel 也是开源的，也能在 QEMU 跑起来一个 Shell ，但是它不接收来自外界的 Patch ，如果我对它的贡献的目的是让自己的 Apple 设备有更好的性能，这样的一个封闭的开源模式又如何让我这样的外部贡献者得以达到自己的目的呢？

而开源 ISA 、 开源处理器，何尝不应该是真正的开源路线呢？

现阶段机遇在哪？

即使 RISC-V 在 ISA 与硬件层面都追上了 aarch64，其软件生态的问题也容易让市场望而却步。更别说目前 aarch64 与 x86 在生态上仍有很大的差距。

我们看到了 RISC-V 在嵌入式与 AI 领域的指令集可裁剪（Flexing RISC-V Instruction Subset Processors to Extreme Edge）、可厂商自定义（例如实现还没 ratified P 扩展、 Matrix 扩展）的巨大优势。

对于通用处理器，我认为优势可以有：在一类特定的 Workload 基于高性能开源核增加软硬件协同设计，在一类特定的 Workload 下做的比现有产品更好。

例如，学术界研究了非常多的新兴应用，比如 FaaS 场景的微架构预热、主要面向图计算和数据结构访问的可编程预取器、在保证系统安全的同时让安全检查开销低到可忽略的软硬件协同安全设计等等，这都是一些做好了可以适配很多很多 CPU 上的通用应用的工作。如果 RISC-V 的生态可以让需要这样处理器的组织，快速地从模拟器的 Evaluation 走向现实世界，这何尝不是开源 ISA 与开源处理器最大的价值呢？

而且，随着开源硬件生态的发展，我们有了 Chisel 这样的敏捷 RTL 生成器语言，从而让开源处理器 RTL 生成也可以像 Linux Kernel 一样提供数千个可配置、可开关的生成器参数；有了 LLVM-CIRCT 这样基于 MILR 的硬件编译器来加入我们想要的 Pass；有了 Verilator 这样的开源 RTL 仿真器。这些生态的存在让普通人参与开源硬件的门槛大大降低，不再有那些专有且昂贵的 EDA 软件挡着个人贡献者的路，也让开源硬件的代码更加易读，让一般的个人也得以轻松上手，这何尝不是一群喜欢探索和改造世界的 geek 们的终极追求？

现在，也许正是一个探索这些新机遇的好时候！