如何设计 ISA
关于如何设计像 RISC‑V、Arm 和 x86 这样的指令集架构（ISA）的争论，与其说围绕某个单一特性，不如说围绕简洁性、性能、功耗、代码密度以及长期生态成本之间的权衡。评论者强调，指令融合、压缩编码、条件移动、内存模型以及面向语言或领域的扩展等细节，可能在不同目标市场中带来好处或坏处，从微小嵌入式核心到高端服务器皆然。许多人得出的结论是，RISC‑V 小而可扩展的基础和开放许可使其成为很可能的长期基础，但也指出，现实世界中的成功将更多取决于微架构实现和软件工具链，而不仅仅是 ISA 本身的优雅。
ISA 设计中的细微差别与 RISC‑V 对比
- 参与者强调，ISA 设计是多维度的；互联网上的争论常常只盯住单一方面（解码简单性、某种条件分支形式等）。
- RISC‑V 因其简洁性和良好的代码密度而受到称赞，尤其是在 64 位上，而且规范中已经明确预期了指令融合。
- 报告称，与 Arm 相比，测得的“路径长度”（动态指令计数）非常接近；有些人认为这“很棒”，另一些人则说这只是“并不更差”，尤其是在只评估了 rv64g 且忽略了融合/扩展的情况下。
- 许多人认为，简洁性以及与 Arm 相近的性能是一项重大胜利。
条件移动、寻址模式与压缩指令
- 关于基础 RISC‑V 缺少条件移动和更丰富寻址模式的问题，存在争论。
- 一方认为：主张增加这些特性的人应当用真实硅片和数据证明收益。
- 另一方认为：来自其他 ISA 的经验表明这些特性确实可能带来非平凡收益，不过相关数字很少。
- 压缩（C）扩展：
- 支持者表示，它能改善代码尺寸和指令缓存行为；大型内核设计者报告称，只要从一开始就把它设计进去，控制起来是可行的。
- 批评者强调复杂性：错位、页面/PMA/PMP 边界问题、与 CHERI 的交互；一些厂商提出了替代编码，甚至提出“all-in”式的大改动，而其他人对此强烈反对。
兼容性、未定义行为与事实上的规范
- 一个关于 486 标志位“bug”被游戏依赖的故事说明了，规范中“未定义”的行为如何会变成事实上的必需品，迫使未来芯片去模拟它。
- 这也联系到更广泛的一点：真实世界中的规范往往最终会变成“主导实现所做的一切”，而不只是书面文档本身。
面向领域的指令与语言目标
- 有人主张自动探索面向 JavaScript/Python 等语言定制的大型复杂指令设计空间。
- 反对意见：
- 这类语言并不存在单一瓶颈，而且工作负载会演变。
- 过去的领域专用 ISA 特性（例如 JVM 执行、重型寄存器窗口）往往只在很窄的条件下取胜，或在真实世界中的回报令人失望。
- 专用加速器（媒体、ML）已经很常见，而且对许多任务更合适。
ISA 与微架构、功耗和性能
- 一种观点是：说某个 ISA“更快”，就像说某种语言的语法“更快”一样；多数结果取决于实现。
- 另一些人回应说，ISA 语义会像语言 API 一样约束实现，并可能带来持续性的开销（例如，语言类比中的强制堆分配 vs 栈分配）。
RISC‑V 生态、可扩展性与未来
- 有人预测 RISC‑V 会占主导地位并冻结 ISA 设计；也有人预计会通过自定义扩展出现明显碎片化，甚至在高端需求分化后出现未来的“RISC‑VI”。
- 极小的基础 ISA 加上标准化扩展机制，被视为既是优点（复用、开放），也是张力来源（重叠或竞争的扩展、兼容性配置文件）。
- 规范和操作系统中都存在在运行时查询所支持扩展的机制；生态系统能否很好地处理大量自定义扩展，被视为一个开放的软件问题。
业余与实验性 ISA
- 有几位提到了他们个人设计的 ISA 和 CPU（受 x86 启发但更简化、带有时序保证的 RISC 风格信号处理核心、类似 SuperH 的紧凑型 2 操作数 16 位编码）。
- 这些例子说明了代码密度、指令数量、编译器复杂度与硬件简洁性之间的权衡，并表明即使在主要厂商之外，ISA 实验也仍在继续。
软件生态与文档
- 新 ISA 的一大障碍是工具链和生态系统：内核、主流编译器/JIT、数学/加密/媒体库。
- 开源在一定程度上降低了这一门槛，而半自动化的编译器后端生成也正在出现。
- 另一个挑战是缺乏公开共享的微架构数据和时序模型；大多数实际结果仍然是专有的。
- GPU 被视为一个极端例子：硬件 ISA 故意隐藏在厂商 IR 之后，从而允许在不破坏软件的情况下进行激进变化，这与寿命很长的 CPU ISA 不同。