RISC-V：本该更明智的选择

RISC-V: They Should Have Known Better

▲ 17dmitrygr191 HN 评论区
RISC-V：本该更明智的选择

我常被问及为何对RISC-V持保留态度，这次决定系统阐述。RISC-V试图通吃从超算到廉价微控制器的所有场景，但这在架构设计上本就不可能。在嵌入式领域，其中断处理开销远超Cortex-M0，压缩指令设计也存在明显缺陷；而在高性能计算中，变长指令阻碍了并行解码效率。作者指出，RISC-V的许多问题本可避免，却因缺乏远见而遗留至今。尽管它可能在低成本微控制器市场占有一席之地，但这并非源于其ISA设计的优越性，而是竞争对手的门槛太低。

RISC-V最终将占据廉价的一次性微控制器市场，但这并非因为其指令集架构设计出色，而是尽管有这些设计缺陷。
阅读原文 →HN 评论区

HN 评论区

191
  1. wren6991

    RISC-V……还行。它满足了我作为业余 CPU 设计师对指令集架构（ISA）的两个要求：

    1. 主线 LLVM 和 GCC 都支持。

    2. 我可以实现它，而不用担心律师给我发“情书”。

    其他问题，我都可以后期修复。扩展指令集中散布着足够多的好点子，让我能组装出一个相当完善、经过精心挑选的嵌入式指令集，兼具有竞争力的性能和代码密度，同时实现起来也很简单。

    我觉得 Dmitry 的观点大体上切中要害，不过我还是要按惯例提个法定投诉：凡是包含 RISC-V J 格式位域图的 rant（吐槽文），都应该配上一张类似的 Arm T32 BL 编码图。

  2. xiphias2

    如果 RISC-V 足够好，能让 AMD 将其用于 GPU 控制器，且成本低于 ARM，并且 NVIDIA 也在许多地方使用它，那么与其等待 Jim Keller 批准 ARM/x86 的授权变更，不如在此基础上构建。它已经足够好了。

    事实证明，等待数年以更改指令集架构的成本，比修复它现有的任何问题都要高。

  3. camel-cdr

    我对这篇文章的异议主要集中在以下几点：

    RISC-V 不是一个指令集架构，而是一个指令集生成框架。

    如果 RISC-V 当初 1 对 1 地标准化了 aarch64，最终结果依然会是一团扩展指令集的烂摊子，因为很多人（RVI 成员）有不同的需求，并且非常乐意构建自己的子集，这些子集随后会被上游合并，因为多家厂商想要相同的子集并需要它们之间的兼容性。显然，如果 RISC-V 诞生时就已完成 RVA23 会好得多，但开发需要时间，而 RISC-V International 成立时，人们已经在用 RISC-V 了。

    RISC-V 也是被“拒绝服务攻击”（DOS）最严重的指令集，人们不断提出疯狂的提案。就在前几天，有人提议一条指令，在最大 VLEN 下能一次性完成多达 2^30 次 16 位比较。因为他们想改进字符串处理用例。

    ---

    据我经验，RVA23 的微操作（uop）数量（无融合）与 aarch64 和 x86 相当，代码密度更好，指令数量略多。aarch64 相比 RVA23 在指令数量上的最大优势来自单条指令：load-pair（成对加载），它在所有高性能实现中都会在解码阶段被拆解（cracked），因为它写入两个寄存器。

    Arm 提升代码密度的方法是使用多条回写指令，这些指令必须被拆解；而 RISC-V 用的是 RVC。两者都阻碍了并行解码的简单线性扩展，所以代码密度对 Arm 来说似乎足够重要，以至于让他们……

  4. bjornnn

    RISC-V 的重要意义和吸引力，以及中国目前大力投资它的原因，与它内部运作的技术细节关系不大，关键在于它是一个不受知识产权法束缚的开放标准。即使它在技术上不是最好的通用处理器架构，它也树立了一个重要的先例：证明开发一种全球通用的开放公共架构是可行的，世界可以用它来构建计算设备，而无需被收取授权费的多国公司勒索，也无需受地缘政治大国实施的关税和制裁影响。

  5. Neywiny

    我想我懂了。我试用过 microblaze-v 一段时间。看看他们的中断处理程序就知道了。https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta...。如果在编译时启用了 FPU，每次中断就要进行超过 128 次内存操作。这简直疯了，尤其是没有 NVIC、没有链式处理等机制的情况下。我的延迟高得离谱，最大中断频率也惨不忍睹。最后我不得不做工作（软件和硬件方案）让它更像 arm-m 那样运行，但 arm-m 根本不需要做这些工作。NVIC 永远是 NVIC，而且 NVIC 很好。

  6. Retr0id

    我最近写了一个 RV64IMA 模拟器。我只需要一个能启动 Linux 的虚拟 CPU 核心，而 RV64IMA 似乎是最简单的方法——而且我想这大体上是真的。

    但随后我想兼容现成的工具链和二进制文件，结果发现自己需要将指令集配置文件扩展到 RV64GC。这不算太大的工作量，但需要引入一个软浮点库。这让我成功启动了 Alpine Linux。

    然后我想启动 Ubuntu，这就需要 RVA23，相比之下工作量大了很多，涉及向量指令集等众多内容。到了这一步，我觉得我当初直接模拟 aarch64 会更好。

  7. kev009

    这基本上就是 MIPS 重蹈覆辙。

    结论很诚实，当然你也可以通过暴力手段让任何指令集适应任何角色。我以前因此痛恨 x86，但现在年纪大了，反而欣赏这种游戏。

  8. camel-cdr

    我对这篇文章的异议主要集中在以下几点：

    RISC-V 不是一个指令集架构，而是一个指令集生成框架。

    如果 RISC-V 当初 1 对 1 地标准化了 aarch64，最终结果依然会是一团扩展指令集的烂摊子，因为很多人（RVI 成员）有不同的需求，并且非常乐意构建自己的子集，这些子集随后会被上游合并，因为多家厂商想要相同的子集并需要它们之间的兼容性。显然，如果 RISC-V 诞生时就已完成 RVA23 会好得多，但开发需要时间，而 RISC-V International 成立时，人们已经在用 RISC-V 了。

    RISC-V 也是被“拒绝服务攻击”（DOS）最严重的指令集，人们不断提出疯狂的提案。就在前几天，有人提议一条指令，在最大 VLEN 下能一次性完成多达 2^30 次 16 位比较。因为他们想改进字符串处理用例。

    ---

    据我经验，RVA23 的微操作（uop）数量（无融合）与 aarch64 和 x86 相当，代码密度更好，指令数量略多。aarch64 相比 RVA23 在指令数量上的最大优势来自单条指令：load-pair（成对加载），它在所有高性能实现中都会在解码阶段被拆解（cracked），因为它写入两个寄存器。

    Arm 提升代码密度的方法是使用多条回写指令，这些指令必须被拆解；而 RISC-V 用的是 RVC。两者都阻碍了并行解码的简单线性扩展，所以代码密度对 Arm 来说似乎足够重要，以至于让他们……

同日更多故事

2026-08-15