【外评】Linus Torvalds 称 RISC-V 将重蹈 Arm 和 x86 的覆辙

116 条评论 | |

硬件和软件开发人员之间存在着巨大的差异，这给试图协调两个团队的人员带来了隐患。Arm 和 x86 研究人员多年前就遇到过这种情况，Linux 的创始人 Linus Torvalds 担心 RISC-V 的开发可能会再次陷入同样的困境。

“他说：”即使你以更开放的方式进行硬件设计，硬件人员与软件人员之间的差异也非常大，Verilog 与内核之间存在着相当大的鸿沟，更不用说在更高的堆栈中，你所从事的工作与硬件相去甚远，以至于你真的不知道硬件是如何工作的。

“他说：”因此，要跨越这个巨大的鸿沟工作真的很难，我怀疑硬件设计人员，他们中的一些人有一些重叠，但他们将通过犯错来学习–所有以前犯过的同样的错误。

RISC-V 是一种用于处理器的开放标准 ISA，它正在慢慢受到重视，尤其是在中国，一些科技公司正在利用它来绕过美国对中国的制裁。DeepComputing 和 Framework 等公司已经开始开发、制造和销售采用这种新处理器的消费类笔记本电脑。

不过，尽管 RISC-V 正在慢慢发展壮大，但其性能仍无法与当前的 x86 和 Arm 处理器相抗衡。要在 RISC-V 芯片上玩 AAA 级游戏，仍需要数年或数十年的开发。不过，尽管同样采用精简指令集计算机（RISC）架构的 Arm 已经经历了深入开发，但 Linus 担心 RISC-V 仍会重蹈覆辙。

“他说：”它们会遇到我们在 Arm 方面遇到的所有问题，以及 x86 之前遇到的问题。“他们需要几代人的时间才能说，’哦，我们没有想到这一点’，因为他们有新的人参与进来。

不过，即使预计 RISC-V 的开发仍然会犯很多错误，他也表示，现在开发硬件要容易得多。Linus 说：”真正达到 Arm 和 x86 在相当平等的基础上竞争的地步花了几十年的时间，因为以前的这些软件都是相当以 PC 为中心的，而现在这种情况已经过去了。这将使 RISC-V 等新架构更容易进入市场。

本文文字及图片出自 Linus Torvalds says RISC-V will make the same mistakes as Arm and x86

你也许感兴趣的：

共有 116 条讨论

  1. 标题不妥，他在发言前说 “我担心”，“说 ”本可以写成 “担心”。

    预计 RISC-V 的执行不会（也从未）无懈可击，这很现实

    上下文是关于幽灵的

    回复

    1. Torvalds拥有足够广度和深度的经验，因此将他对协调硬件和软件的担忧视为专家的担忧并非不合理。当然，与年轻时相比，如今托瓦尔兹的批评往往更加委婉。

      回复

      1. 正是如此。很多人都忘了或不知道他以前也从事过 CPU 硬件方面的工作（Transmeta）。

        >当然，与年轻时相比，如今的托瓦尔兹在批评时会更加委婉。

        这也是他对 Rust 和 RISC-V 非常谨慎的原因。

        而且，从父母的角度来看， > RISC-V 的执行不会（而且也没有）完美无瑕，这也是很现实的。

        但大多数 RISC-V 支持者都声称 RISC-V 的每一次执行都是完美无瑕的。

        回复

        1. > 除了大多数 RISC-V 支持者一直声称每一次 RISC-V 执行都是完美无瑕的。

          也许是无懈可击。

          大概有几十家公司正在设计 RISC-V 内核，还有更多公司正在制造芯片（例如 SiFive 的内核就有 100 多家客户）。它们或多或少都有一些严重的勘误表，就像每个 Arm 和 x86 芯片一样。

          它的优势在于多样性，在于实验和创新的自由，在于共享的软件生态系统，在于如果你的芯片供应商因任何原因（破产、计划改变、被收购……）倒闭，你总能找到另一家供应商的安全感。

          而那些依赖 Itanium、DEC Alpha、Motorola 68000、z80 和其他几十家厂商的人则不同。

          回复

          1. > 优势在于多样性、实验和创新的自由以及共享的软件生态系统

            RISC-V 有标准化的设备发现机制吗？我听说对 ARM（？）的一个批评是，对于每个芯片制造商来说，总线发现和总线上设备发现基本上都要重新发明轮子。

            回复

            1. 设备树似乎是标准配置，就像 ARM 一样。

              回复

          2. 这个。

            我经常听到 Amiga 的用户说，如果不是 Commodore 管理不善，Amiga 在当今的计算机时代 “本可以大放异彩”。如果当初 Commodore 没有收购 Amiga 公司，而允许才华横溢的革命家 Jay Miner 以自己的方式销售他的设计，而不受制于那些想压榨他们以获取利润的邪恶企业霸主，那该有多好。但愿如此。但愿如此。

            但很明显，从 20 世纪 80 年代末开始，个人电脑就将获胜，因为它不受一家公司的控制。事实上，尽管 IBM 开始失误，但它还是赢了。从长远来看，所有公司都有管理不善的倾向，如果一个平台在它们的控制之下，就会彻底完蛋。这种情况曾发生在 Commodore、Atari、Symbolics 和 SGI 身上，90 年代的苹果公司也差点遭遇这种情况，而在不久的将来，树莓派（Raspberry Pi）也可能遭遇这种情况。但是，如果有一个开放的标准，各家公司在互操作的同时也能参与竞争，那么这个平台就会茁壮成长，并能在其基础上创造出其原创者无法想象的东西。

            RISC-V 为芯片架构和 ISA 带来了这种特质，就像 Linux 为操作系统带来了这种特质，x86、ISA/PCI 总线和 BIOS/UEFI 接口的组合为通用系统设计带来了这种特质一样。它并不完美，任何实现方式都不会完美，但 RISC-V 确实会改变一切。

            回复

            1. 很遗憾我只能给一个向上的投票。

              回复

      2. 我没有读到任何东西，但如果他说的是 “我担心 ”而不是 “我认为”，这就是警告与预测之间的区别。标题让人觉得他是在预测。

        回复

      3. Linus 现在对 CPU 硬件的看法仍然是错误的，就像他当年一样。例如，他过去一直坚持认为 ISA 对性能没有任何影响。我们只需看看苹果 M 内核（10 宽指令取指令）相对于任何 x86 处理器的巨大单线程性能和效率，就会发现这种说法是不正确的。我不认为我会把他的硬件断言当作福音。

        回复

        1. > 例如，他过去一直坚持认为 ISA 对性能没有任何影响。我们只需看看苹果 M 内核（10 宽指令取指令）相对于任何 x86 处理器的巨大单线程性能和效率，就会发现这种说法是不正确的。

          你的论点是 ISA 会影响性能……而你的例子是 ARM，它的性能从全面不如 x86，到有时能击败 x86，是因为一家公司比其他公司做了更好的实现？这似乎是一个很好的例子，说明 ISA 并不是影响性能的主要因素。

          回复

          1. 与 x86 相比，苹果芯片在每瓦性能方面完全占据优势。Arm64 简单的固定长度指令集绝对是其中的核心。高通公司（Qualcomm）的移动芯片性能现已超过英特尔，这进一步证明了 ISA 的重要性。在数据中心，graviton 4 以及最终的 grace hopper 也将实现这一目标。

            总之，我的观点并不是实施不会影响性能。当然有影响。我的观点是，Linus 断言 ISA 与性能无关，只有执行才是最重要的。这种说法站不住脚。

            回复

            1. >在这一点上，Arm64 的简单固定长度指令集绝对是核心。

              需要注意的是，采用可变指令长度本身并不是一个问题，更密集但仍易于解码的 RISC-V 已经证明了这一点。

              然而，x86 的解码成本非常高，而且整体上非常糟糕。

              回复

              1. 是的，这里面有很多细微差别。并不是所有的可变长度等式都有问题。X86 绝对是。

                回复

            2. TLDR：RISC-V 的 2 字节和 4 字节双指令长度在任何实际 CPU 宽度下都没有明显的解码缩放/延迟问题。

              双指令宽度在减少代码大小、提高高速缓存利用率、减少指令取回带宽等方面具有很大优势，而且成本非常低。

              RISC-V 指令长度解码只需查看每 2 字节代码的 2 位（这 2 位上的 AND 门可将其减少为 1 位）。因此，解码 32 字节代码（其中包含 8 到 16 条指令，平均约为 11 条）只需查看 16 个信号。这已经接近查找表的范围了。

              事实上，解码的方法（至少是我想到的方法）是为每组 4 个对齐字节加上前 2 个字节（共 6 个字节）制作一个解码器。

              每个程序块可以解码一条指令（一条对齐的 4 字节指令，或一条从上一个程序块开始的未对齐的 4 字节指令，然后是第二条未对齐的 4 字节指令，该指令留给下一个程序块解码）或两条指令（两条 2 字节指令，或一条从上一个程序块开始的未对齐的 4 字节指令，然后是一条 2 字节指令）。

              每个区块接收一个信号，说明前一个区块是否消耗了最后两个字节，并向下一个解码器区块输出一个类似的信号。因此，你可以通过菊花链的方式，用 8 个这样的解码器块来解析 32 字节的代码。

              这并不是一个巨大的延迟。

              但你可以做得更好。

              每个区块都会产生两个信号，一个信号表示，如果前一个解码器区块耗尽了该组的所有字节，那么该组的最后两个字节是否被耗尽；另一个信号表示，如果前一个解码器区块没有耗尽该组的最后两个字节，那么该组的最后两个字节是否被耗尽。

              这些信号可以看作是 “生成 ”和 “传播 ”信号，类似于全梯形图的进位输出。

              这两个信号可以并行生成，与前面的所有区块无关。你甚至可以使用三种解码器，以两种可能的方式解码一个或两个完整的指令：一个从 -2 字节开始的仅 4 字节解码器，一个从 +2 字节开始的仅 2 字节解码器，以及一个从 +0 字节开始的既能执行 2 字节指令又能执行 4 字节指令的解码器。

              然后，你可以使用与进位前瞻加法器相同的技术，选择使用每个解码器块的解码输出（一条或两条指令），其缩放特性与加法器相同。

              只不过，如果每个周期只解码 32 字节代码，那么就相当于 8 位加法器，在这种情况下，前导几乎不值得使用。在 16、32、64、128 位加法器中，这种技术才会发挥其作用。这相当于每循环解码 64、128、256、512 字节的代码，由于基本块长度和预测多分支，这远远超出了实际 CPU 的范围。

              代价是每 4 字节代码需要三个解码器，同时最多产生两条指令，不过第三个解码器只需处理有限的 2 字节 C 扩展指令集（另外两个解码器中只有一个需要 C 解码器）。

              注意：只需一个全强度（2 字节和 4 字节）解码器和一个仅 2 字节解码器，并使用 “进位 ”输入将 -2…1 字节或 0…3 字节 MUX 到全强度解码器中，就可以节省解码器，但会有一点延迟。

              是的，它比相同宽度的 Aarch64 解码器复杂，但完全可以管理，而且比 x86 简单得多。

              回复

              1. 是的，当指令的大小不在 1-15 字节之间时，它绝对是可控的。

                回复

    2. 我不确定他说的是内核本身。在我看来，更有可能的是生态系统的选择，比如预启动环境。

      回复

    3. Torvalds的直接引语中根本没有使用 “恐惧 ”一词

      文章引用 Torvalds 的原话是 “我怀疑……”。

      文章作者用 “恐惧 ”来修饰这句话

      在发表评论之前，我们需要做一个测验；你读过这篇文章吗？并询问有关随机片段的书面背景。

      回复

  2. > RISC-V 是一种开放标准的 ISA 处理器，它正逐渐受到人们的关注，尤其是在中国，一些科技公司正利用它来绕过美国对中国的制裁。

    我真的不喜欢这种说法，它根本没有意义，因为 MIPS 已经存在，而且对于 RISC-V 的应用来说绰绰有余。关于 Linux 也可以这么说，但提出这个问题显然是荒谬的。

    回复

    1. >> […]一些科技公司利用它来绕过美国对该国的制裁。

      > 我真的不喜欢这种说法，因为 MIPS 已经存在，而且对于 RISC-V 的应用来说绰绰有余。

      如果中国的一些科技公司真的把 MIPS 用于这样的用途，这还叫 “说法 ”吗？

      甚至 MIPS 公司也在转向 RISC-V：

      > 大学和技术学校的计算机体系结构课程经常学习 MIPS 体系结构。2021 年 3 月，MIPS 宣布结束 MIPS 架构的开发，因为该公司正在向 RISC-V 过渡[10]。

      * https://en.wikipedia.org/wiki/MIPS_architecture

      > 2022 年 5 月，MIPS 预览了其首款 RISC-V CPU IP 内核 eVocore P8700 和 I8500 多核处理器。

      * https://en.wikipedia.org/wiki/MIPS_Technologies

      回复

      1. > 如果一些中国科技公司真的将其用于此类目的，这算不算 “叙述”？

        我并不是说这种说法是错误的，只是在介绍 RISC-V 时提出这种说法太荒谬了。关于 Linux 也可以这么说，但如果在介绍 Linux 时说 “Linux 被用来绕过美国的制裁”，这显然是错误的。

        > 甚至连 MIPS 公司也在转向 RISC-V：

        我不知道，但我想说的是，MIPS ISA 是开放的，可以替代它。RISC-V 并没有什么特别之处。

        回复

        1. >> 我不知道，但我想说的是，MIPS ISA 是开放的，可以替代它。RISC-V 并没有什么特别之处。

          市场份额。RISC-V 在全球受到关注，而 MIPS 却没有。围绕 RISC-V 的软件生态系统得到了来自世界各地的贡献，而 MIPS（更糟糕的是，修改过的中国 MIPS）实际上只是在中国。他们将从使用更广泛的产品中获益。因此，尽管 RISC-V 在技术上可能并不特别，但在某种意义上却 “更好”。

          举例来说，中国和谷歌都在努力将安卓系统引入 RISC-V，而 MIPS 却并非如此。

          回复

        2. 感觉这似乎是对技术的一种负面评价，但其实不应该这么看。

          回复

          1. 我不认为这是一种负面的倾向，而是它被采用的主要原因之一。

            即使这与架构本身的优势关系不大。

            回复

    2. 我不记得在 MIPS 领域有任何此类设计是在如此宽松的条件下发布的。

      回复

      1. 试想一下，如果有一大批公司联合起来，共同开发开放式内核设计，可以避免多少金钱和风险。我们可以将 CPU 市场完全商品化，全面降低成本，就像 Linux 对服务器操作系统或 Android 对手机所做的那样。

        回复

  3. 在成为高级工程师后，我学到的一点是，如果你的上一层有足够的利润，你就应该在自己的层中构建与上一层抽象相匹配的次标准实现。总的来说，系统的性能会比你针对自己层的瓶颈进行优化要好得多。

    回复

    1. 这里听起来很有见地，但对我来说有点模糊。你能提供更多细节吗？

      回复

      1. 当然可以。

        假设你要从头开始编写一个操作系统，供人们使用，而不是供数据中心的服务器使用。

        你应该做的就是尽可能以最低的延迟来构建系统。即使你的 CPU 有一半时间都在忙于等待用户输入。忽略传统操作系统的吞吐量吧。用户不会因为一项工作耗时 20 分钟而不是 10 分钟而感到恼火，也不会因为一个窗口调整大小需要 3 秒钟而感到恼火。

        这违背了工程师的所有本能，因为你并没有针对你所在层的稀缺资源–CPU 周期–进行优化。

        我摆脱这种脑损伤的方法就是找到对最终用户最重要的指标，并将其追溯到我可以控制的层，然后对其进行优化。

        回复

        1. > 即使你把一半的 CPU 周期都耗费在等待用户输入的繁忙工作上。

          当然，当人们希望它在电池供电的设备上运行时，你就会碰壁。

          回复

          1. 你不可能面面俱到。不过我想你的耗电量还是会比现在普通的 JS hot mess 少。

            回复

        2. 谢谢，这条评论和来自 afiori 的 40986327 条评论让我茅塞顿开。

          回复

        3. 所以，优化是为了用户体验，而不是有效利用资源？

          回复

          1. 更像是优化整个产品的质量，而不仅仅是优化你的独立组件的质量

            回复

          2. 你的用户可能是另一个应用程序，它的瓶颈比你自己的瓶颈昂贵得多。

            回复

      2. 从技术上讲，这违反了 “关注点分离 ”原则，但如果它能带来结果，那它就能带来结果。

        回复

        1. 如果这些指令就像宏一样，比扩展指令更快，那么这就不是真正意义上的取舍。

          如果指令具有某种神奇的一次性效果，那就违反了规定。

          回复

  5. 有任何关于Windows RISC-V机器的消息吗？

    我刚刚升级了用了 6 年的联想 X1，差点就想买 ARM（骁龙）机器了，但又觉得太不靠谱，而且我知道我需要做的一些事情会有软件问题，所以还是坚持用 x86（AMD）。

    如果软件能与之匹配，我可以很容易地做出下一次选择，甚至是 RISC-V。

    回复

    1. 我们知道微软正在研究它，但仅此而已。

      至于什么时候，我们还不得而知，但我希望它能与有能力的硬件一起出现。

      回复

    2. >> 关于 Windows RISC-V 机器的讨论还要持续多久？

      我敢打赌，Android 会最先出现。

      回复

  8. 在我看来，复杂的指令是不可避免的，除非使用情况仅限于微控制器。现代 ISA 的 CPU 功能标志应允许实现者禁用复杂而昂贵的指令集。

    举例来说，ARM 是 CISC/RISC 的混合体，armv8-a 是完全的 CISC，而 armv8-m 则是 RISC。无论如何，这就是我的建议。

    回复

    1. 你把复杂与利基混为一谈了。

      RISC 兼容小众，避免复杂。

      iAPX432 就是复杂的例子，其 ISA 中包含了 OOP、垃圾回收甚至数据结构等内容。这些指令非常复杂，需要大量的周期才能完成。

      与此相反，大量的位操作指令是利基指令，但其中任何一条指令都可以在 1 个或 2 个周期内完成。

      AES 也是如此，即使 x86 也采用了类似 RISC 的方法，即调用几条简单指令进行设置，然后为每一轮调用一条简单指令（1-2 个周期），最后调用一些简单的终结指令。每条指令都很细微，但并不复杂。

      回复

      1. 也许我把两者混为一谈了，但我想说的是实现成本。无论是否利基，最大限度地降低硬件成本对消费者和供应商都很重要。另一方面，对于通用计算而言，复杂指令可以提高性能，而 “利基 ”指令集也是如此，它们未必如你所说的那样复杂。由于 ARM 并不实际制造硬件，它应该让供应商根据自己的要求选择要实现的功能集，然后 ARM 程序可以在尝试条件执行之前测试这些静态寄存器的值。

        回复

    2. 您的意思是反过来吗？-m适用于简单（r）微控制器，而-a适用于应用处理器。

      回复

  9. 预言事情不会完美发展的人并不是诺查丹玛斯。但历史就是这样，它给了你不重蹈覆辙的机会。RISCV 会吸取历史教训吗？

    回复

  10. 1. 想要更简单的 ISA

    2. 建立它

    3. 意识到在关键用例中添加一条复杂而奇怪的指令能真正提高性能

    4. 重复第 3 步，直到有人认为你的 ISA 过于复杂，并制定出新的 ISA

    回复

    1. 不仅仅是指令集架构。我觉得软件也可能如此。

      1. 想要更简单的应用程序

      2. 编写应用程序

      3. 意识到添加复杂而奇怪的代码确实能提高性能

      4. 重复第 3 步，直到有人认为你的程序过于复杂，并制作了一个新程序为止

      我想这里的寓意是，计算机是复杂的，而试图避免复杂性是很难或不可行的。

      回复

      1. 但这通常不是性能问题，而是功能问题。然后它就会变得臃肿。有人认为他们不需要这些垃圾。

        但事实证明他们需要。

        回复

        1. 我觉得有很多行业就是因为这样而存在的

          回复

        2. 每个人都会使用文字处理软件中大约 5%的功能，但每个人使用的子集不同，因此所有功能都有人需要，而且大多数功能的使用率相同。

          回复

          1. 我认为事实并非如此。常用功能肯定有多有少。每个人都使用基本格式，但只有少数用户使用索引或书目功能。这些功能对这一小部分人来说可能很重要，但它们的使用率却不尽相同。

            回复

            1. 每个人都使用的是少数。它很快就会消失。

              回复

        3. 问题在于，在不考虑现有功能的情况下添加了新功能。很多应用程序都是这样，用多种方法做完全相同的事，但使用情况却略有不同。

          回复

      2. 或编程语言设计。不过，我认为在这一过程中，仍会对事物进行提炼，从而纳入新的通用模式。我相信，鉴于开发人员当时所面临的限制，在上世纪 70 年代，空端字符串并不是一个特别糟糕的想法。只是后来我们有了不同的限制条件，积累了更多的经验，从而最终意识到这是一种不安全的设计。

        回复

        1. 我认为，人们基本上一直都知道空端字符串是不安全的（毕竟 strncpy 早在 70 年代就已经存在了[1]），只是直到最近，人们才发现替代方案的各种代价（性能、复杂性、后来的互操作性）是值得的。Pascal 一直将长度前缀字符串作为默认设置，它与 C 是同时代的语言。

          [1]: https://softwareengineering.stackexchange.com/a/450802

          回复

        2. 我们又回到了帕斯卡字符串，只是现在我们不介意使用 32 或 64 字节的长度前缀了。在我们介意的情况下，我们现在愿意在可变长度整数上花费几条指令。

          但从更广阔的角度来看，编程语言的轮子是重塑的一个积极范例。我们确实在语言设计方面做得更好。这不仅是因为更好的硬件和更好的编译器让要求变得更宽松，还因为我们已经积累了几十年的经验，知道哪些模式和语言特性是可取的。当然，集成开发环境的发展也起到了巨大的作用：良好的缩进处理对于 python 等语言至关重要，而自从 LSP 使智能自动补全变得无处不在后，强类型也变得更加流行。虽然老式语言也在尝试融入新的发展，但很多老式语言已经把自己设计到了角落里。这正是新语言能够获得真正优势的地方，因为新语言从一开始就使用了最新的见解和可能性，在标准库设计中依赖于这些见解和可能性，并摒弃了过时的旧模式。

          没有哪种现代语言还会引入名为 strstr、atoi 或 snwprint 的函数。自动补全和大屏幕使这些函数名的概念成为反模式。但 C 语言却无法轻易摆脱它们。

          回复

      3. 我认为 “软件 ”一词过于宽泛，必须将比较范围缩小到软件开发的一小部分才有意义。在软件开发中，你通常要面对的是模糊且不断变化的需求，如果你开发了五个简单的应用程序，希望其中四个能基本满足要求，只需要逐步增强功能，而只有第五个需要做大量的工作，以适应问题的复杂性。(这个比例可以根据不同的领域进行调整）。

        在这种情况下，他们正在为一个问题创建一个新的解决方案，而之前所有的解决方案最终都会变得极其复杂，而且目前在 x86 和 ARM 上运行的现有软件为他们提供了一套具体的示例，说明他们需要快速开发的软件类型，因此他们所处理的需求信息要比几乎所有软件项目都要多得多。

        我能想到的最接近软件开发的等价物是构建一个新的网络浏览器。所有现有的网络浏览器都极其复杂，而且你有数百万个现有网页可供测试。

        回复

      4. 是的，肯定是这样。我们认为，经过一两年的运行，规格已经基本定型，所以现在的重点是让速度更快，这需要非常复杂的算法，但不用担心，一旦我们完成了，就不用再改变了！对不对？……然后新的用例就来了。新的功能需求出现了。我们想让当前的代码适应新的情况，同时仍然覆盖现有的情况，并保持我们一路走来所获得的所有性能提升。但是代码太乱了，不从头开始是不可行的。

        回复

      5. 你对编程的理解太肤浅了，以至于无法通过解释原因来弥补 🙁

        回复

          1. 举例说明，最后一句话大致相当于 “我想计算机科学是不可行的”。

            但事实并非如此；Debian UNIX 可以运行当今所使用的编程语言，这一事实证明我们已经处理了大量的复杂性问题；相比之下，ENIAC 的编程语言只有婴儿大小。你肯定希望使用 Debian，而不是被后者所束缚，因为你可以神奇地不使用现有的系统–而必须在磁带或 Debian 系统上从头开始编写整个程序。

            这条评论还有很多其他层面的问题，但要知道，无论你在理智上多么诚实和善良，你都不可能回复每一个说错的人，并告诉他为什么错。通常情况下，“你错了 ”可能更有价值。不过，我不想争论这个问题。

            回复

      6. ……或者你也可以作弊，把奇怪的代码写成一个单独的子程序。

        回复

    2. 虽然我相信在 RISC-V 的情况下，每个供应商都会同时意识到这一点，但他们不会告诉任何人，而是做了一个扩展，现在同一个操作有五种不同的不兼容编码。

      回复

      1. 这并不重要，因为

        – 这些自定义扩展都是在自定义扩展空间中进行的。

        – 必须跨供应商工作的软件生态系统既不会使用这些扩展，也不会使用它们。

        – 如果这些扩展确实有用，那么它们的经验就会被用来制作标准扩展，而标准扩展会在某个时候成为标准配置文件，从而被软件生态系统所采用。

        回复

      2. 开源从根本上改变了这种状况。你只需要一个支持你的处理器的 GCC/LLVM 维护版本，你就能拥有支持你的需求的发行版。特别是如果只是需要一些性能提升指令的话。这不会是个问题，因为在大多数情况下，我们已经不再是二进制世界了。

        回复

    3. RISC-V 拥有成为唯一真正的微控制器 ISA 的绝佳机会，但在整个过程中，试图成为 “无所不包、无处不在、一气呵成 ”的 ISA 的努力却令人目不暇接。

      回复

      1. RISC-V 不是一个 ISA，而是一个 ISA 系列。这就是为什么它有一个小内核和大量扩展。因此，你现在拥有的不是一打完全不同的 ISA，而是一打几乎相同的 ISA。它可以根据需要进行分叉和定制。

        理想情况下，您可以从一篮子已批准的扩展中进行选择，以满足您的需求。那么，如果没有其他人拥有与您完全相同的扩展集呢？如果与已支持的芯片共享一个共同的核心，支持起来就容易多了。

        看看有多少编程语言使用 C 语言，而学习 C 语言又比学习 APL 容易得多。将 Risc-V 视为未来的 C 语言。

        回复

      2. 看来，要避免处处都想成为万物之灵是很难的。从我们的角度看，这似乎很容易，但当你掌握方向盘时，这似乎是最合理的做法。

        回复

    4. RISC-V 永远比 x86 简单，因为 ISA 的核心不是灾难。大约 90% 的 x86 指令都只有 12 条主要指令。x86 的这些指令错得离谱，而 RISC-V 却做得非常正确。这保证了 RISC-V 始终能正确执行 90% 的代码。

      可变长度编码的主要优势在于代码密度，但 x86 也搞砸了这一点。以前的 ADD 指令是 2 字节。转到 AMD64 后变成了 3 字节，而 APX 将变成 4 字节。RISC-V 只需 2 个字节就能编码大多数 ADD。事实上，x86 平均指令长度为 4.25 字节，而 ARM64 为 4 字节，RISC-V 平均仅为 3 字节。

      x86 在早期犯了很多错误，如奇偶校验标志（今天的奇偶校验标志是因为英特尔试图通过 8008 赢得终端合同）、x87 或近 30 种不兼容的 SIMD 扩展。RISC-V 则避免了所有这些问题，创造出了真正优秀的设计。

      我们还吸取了以往 RISC ISA 的教训，因此像寄存器窗口、大量 “从堆栈填充 X 寄存器 ”或分支延迟槽这样的馊主意是不会出现的。

      我听到有人说 “它也会变得过于复杂”，但我认为真正的问题是 “还有什么可以搞砸的？

      在 RISC-V 没有可借鉴的实例之前，你必须在利基指令的长尾上走得非常远，而且这些边缘指令的使用率并不高，因此在需要时更容易修复。这与 x86 形成了鲜明对比，在 x86 中，即使是最基本的东西也会被搞砸。

      回复

    5. 我很希望看到一种全新的 ISA，它采用 CISC 风格的方法，不包含所有内存危险（和其他故障）。现在的解码逻辑相对于 CPU 上的其他东西来说很 “便宜”，为什么不充分利用它呢？

      回复

      1. 保持关注点分离与 CISC 风格的方法完全相反。如果你要在硬件中实现垃圾回收或 OOP，你必然会以奇怪的方式混淆事物，就像这在软件中也变得不可避免一样。

        回复

    6. MASKMOVDQU 满足了这一要求。这显然是一个首字母缩写。

      回复

    7. 这让我想起了关于标准的 XKCD。

      1. 有 5 种不同的标准。

      2. 一些好心人说：”这太荒谬了，应该标准化。

      3. 有 6 种不同的标准。

      回复

      1. 时间/日期就是最好的例子。我想我已经见过所有可能的变化了，除了把年放在月和日中间。这简直让我抓狂。

        回复

        1. 一个人在海滩上发现了一个闪闪发光的瓶子。

          他擦了擦，一个精灵出现了。

          [精灵：”我将满足你一个愿望，凡人。”

          “我想让我的祖母复活”

          精灵：”抱歉，但起死回生是我的能力所不能及的 也许你想许一个更……更容易实现的愿望？”

          人：”那好吧，我希望全世界都采用 ISO 8601 日期格式。”

          精灵：“……呃，你说你祖母葬在哪里？”

          回复

  11. 他们的任务只有一个：使其与 ARMv8-A 相似，但又不能太相似，以免让 ARM 有任何想法。请参考 SSE4/AVX2 和 NEON，并对其进行足够相似的向量扩展。

    迄今为止，RISC-V 在这两方面都惨遭失败。“只需在解码器中解决“、”只需融合通用习语“、”只需让 vsetvli 快速运行”。当然，ARMv8 或 X86S 的设计者们可没有几十年的经验来做出更好的决定。

    回复

    1. 点题！在 2011 年 10 月 27 日 ARMv8-A 发布时，RISC-V ISA 的核心已经设计完成。我认为没有人预料到这一点–当然，我记得这对我来说完全是个惊喜。

      以下是截至 2011 年 5 月 13 日的 RISC-V 设计：

      https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62….

      将其与 2019 年最终批准的设计进行比较，你会发现细节上有一些变化，但概念上没有变化。

      – 指令编码方式发生了变化，例如将 rd 放在操作码旁边的右侧，而将字面量的 MSB 放在左侧。

      – J 和 JAL 现在合并了

      – JALR 有三个版本（在 func3 中），以区分调用/返回/其他。现在的做法是约定在 rd 和 rs1 中使用哪个寄存器。(这只对返回地址预测堆栈有影响，这是一项高级功能）

      – RDNPC（获取下一条指令的地址）后来变成了 AUIPC（包括向 PC 添加偏移量）

      – 另一方面，它已经具备了 RISC-V 的特性，即加载使用 rd 和 rs1，而存储使用 rs1 和 rs2（偏移分割方式不同）。大多数其他 ISA（包括所有 Arm ISA）在载入和存储时使用相同的寄存器字段，偏移量也在相同的位置，结果是载入使用 rs2 作为目标，存储使用 rd 作为源！

      说真的，除了上述改动之外，这份文件看起来就像 2019 年批准的最终 RV32G/RV64G 规范。(我没有详细查看浮点指令）。

      至于 SIMD — RISC-V 被设计为高级长度不可知向量处理器的控制处理器。去他妈的固定长度 SIMD。

      回复

      1. > 去他妈的固定长度 SIMD。

        问题就在这里。它完全违背了 SIMD 支持的现状，也违背了一切优化的初衷（这是固定长度的 SIMD，可变长度在映射到任何非自动矢量化的东西上时都会遇到巨大问题）。

        现在，我不是 RISC-V 的粉丝，所以，如果有的话，我鼓励他们采用 RVV 的方式。这让它更有可能消亡。

        回复

        1. 我不明白，当它可以非常容易地模仿固定长度的 SIMD 时，它怎么会死。更不用说 Arm 也在推动与长度无关的矢量计算–当然，到目前为止还不是很成功，而且他们还没有脱离 128 位 NEON 矢量寄存器的长度。富士通（Fujitsu）的首个 SVE 实现使用了 512 位矢量寄存器。它曾一度成为世界上速度最快的超级计算机，所以这个概念显然不是垃圾。

          回复

    2. 目前，“只需在解码器中解决 ”是一个完全正确的方法，如果这证明是不现实的，那么他们可以继续添加条件移动扩展或其他什么东西。

      在界面上添加东西远比删除它们容易得多。

      他们所犯的一个错误可能会在以后对他们造成影响，那就是他们的压缩指令扩展。在我看来，即使是在微控制器上，它所提供的功能也占用了太多的指令集空间。此外，它还引入了大量与字对齐有关的边缘情况，这些边缘情况跨越了高速缓存和内存保护边界。

      回复

      1. 程序问题！

        RISC-V C 扩展占用了 75% 的操作码空间。

        16 位 Thumb1 指令占 ARMv7 操作码空间的 87.5%。

        更不用说 “谓词 ”指令占用了传统 ARMv1-ARMv6 指令集 92.75% 的空间。

        RISC-V 的 “32 位 ”操作码空间是 ARMv7 的两倍，是经典 ARM A32 的 3.45 倍。

        回复

  12. 请问谁能创建一个指令集，在使用该指令集的每个处理器上实现整个指令集（即使是微码）？

    你看过 RISC-V 或 x64 吗？它们是指令集扩展的大杂烩，其中大部分重复使用相同的操作码。

    我们有 TB 级的磁盘空间和 GB 级的 RAM。我们可以负担得起操作码中的几个额外位。

    回复

    1. RISC-V 的规格适用于从微控制器到高性能多核服务器级计算机的各种应用。在这些不同的应用中使用相同的功能是不现实的，也不是一个好主意。

      例如，微控制器无法经济地使用 64 位、SIMD、四精度浮点运算、事务内存等功能。因此，提供灵活性而不是锁定单一的高端功能集是有意义的。

      回复

      1. 请注意，售价 2.99 美元的 Milk-V Duo 有两个 64 位 CPU，包括一个 1 GHz Linux 内核，带有 MMU、FPU 和 128 位长度无关向量单元，支持 32 和 64 位 FP 以及 8、16、32、64 位整数。它还有 64 MB RAM。

        如果你说的是 0.10 美元 CH32V003 级别的微控制器，那当然可以。

        https://arace.tech/products/milk-v-duo

        回复

    2. 这真的有价值吗？可以说，像 clz 这样以慢速仿真方式实现的功能比毫无用处还要糟糕，因为特定应用的回退速度很容易就超过通用操作码的仿真速度。

      如果操作速度很慢，你仍然需要进行检测和回退。除非你不在乎性能，在这种情况下，你可以根本不使用花哨的指令。

      回复

      1. 举个更现代的例子，Zen 2 和 Zen 3 上的 pdep 和 pext（BMI2）速度非常慢，尽管它们在技术上是受支持的。因此，任何想要使用它们的代码都必须加上 “但实际上！如果我在 Zen 2/3 上运行，就假装 pdep/pext 不存在”。

        如果你想让每个 CPU 都支持每条指令，而不关心性能，你可以让操作系统在执行非法指令时进行仿真；鉴于没有人会使用任何可能较慢的指令，性能也不会有太大差别，ISA 甚至可能一开始就没有这些指令。在技术上支持所有指令并不能解决任何问题。

        回复

        1. “如果你希望每个 CPU 都支持所有指令……”

          这看起来确实不错。只要有一种简单的方法可以查询某条指令的运行速度是否很慢，这就意味着所有软件都能运行，而那些知道某些指令存在问题的软件，其运行速度与不支持这些指令时的运行速度一样快。唯一的缺点是需要花费大量精力编写指令的仿真程序，但这似乎并不重要。

          回复

          1. 有两种指令你可能有，也可能没有。第一种是向量指令、密码、字符串和 blockmove 等，这些指令通常可以隐藏在库函数中，只需在程序启动时将函数指针设置为正确的版本即可。但其他指令，如……仅举几例…… “ANDN“（rs1 & ~rs2）或 ”SH3ADD”（(rs1<<3) + rs2），它们很自然地就会与所有代码混合在一起。与基础 ISA 相比，它们所节省的费用根本不值得用库来封装。

            回复

    3. > 我们有 TB 级的磁盘空间和 GB 级的 RAM。我们可以在操作码中多加几个比特。

      只是指令需要获取，这需要时间。

      回复

      1. 由于复杂性和延迟，L1 I 缓存的大小似乎有非常严格的限制。

        回复

    4. 有很多公司都这么做。

      这是因为它们不够有趣，不值得投资迭代。

      扩展程序并不真正重复使用操作码。除了极少数例外情况，这些扩展并不是互不兼容的。如果互不兼容的话，X86 将会更加密集。

      回复

    5. 你基本上是在要求结束向后兼容性，要求每一个处理器都有一个晦涩难懂的未知定制 ISA，而且任何人都无法复制，因为你希望指令集的设计能让未来的处理器都无法在现有的指令集上添加哪怕是一条新指令。唯一可行的办法是，每次有新的处理器问世时，都有一个新的指令集。呀，真是个愚蠢的想法。

      回复

      1. IBM PC 时代之前的情况就是这样：每台电脑要么系统架构不兼容，要么 CPU 完全不同。

        回复

        1. 这将使编译器优化变得支离破碎，因为现在编译器开发人员（集体）不再专注于 1-3 个 ISA，而是分散在更多的 ISA 上。

          回复

          1. 编译器开发人员最近似乎都在专注于生成 LLVM IR。

            回复

            1. 是的，但仍有一些人需要做 IR -> ASM。

              回复

      2. 不蠢。这正是 GPU 的工作方式。很久以来，手机就是这样工作的（J2ME）。Azul 的旧 Java 服务器也是这样工作的。

        从架构的角度来看，软件以高级抽象的形式发布，然后硬件配备集成的操作系统/编译器组合是非常不错的。这无疑解放了 CPU 设计人员，让他们可以做一些由于向后兼容性限制而无法轻松完成的工作，同时，只要编译器能识别受益模式，就能立即使用新的硬件功能。

        回复

        1. > 这正是 GPU 的工作原理。

          (英伟达™（NVIDIA®）GPU 并没有一个通用的指令集–它们只是配备了一套工具，掩盖了非常有限的架构系列之间的差异。许多不同的 PTX 指令在不同的系列中具有截然不同的性能特征（因为有些指令实际上并没有经过加固）。

          回复

    6. x86_64 ISA 已经如此支离破碎。

      有一大堆不同的 SIMD（“SSE”）指令集，谁也猜不透你的程序运行在什么系统上。

      有时间就去 cat /proc/cpuinfo 看看 “flags ”下的所有内容吧

      回复

      1. > 有一大堆不同的 SIMD（“SSE”）指令集，谁也猜不出你的程序运行在什么系统上。

        没有那么糟糕。芯片有三个系列–英特尔 Atoms（/E-cores）、Xeons（/P-cores）和 AMD 芯片–在每个系列中，较新的芯片都是前代芯片功能的严格超集。但也有例外，那就是那些糟糕到无人使用的功能（最著名的是 MPX），以及 AVX-512，这些功能在 Big-little 事件发生之前就已经出现在台式机 P-cores 中，但由于 E-cores 不支持 AVX-512 而被关闭。

        如果你的电脑没有超过十年的历史，那么你的硬件拥有哪些 SSE 指令集就不是猜测的问题了–它拥有所有的 SSE 指令集。

        回复

        1. 在哪里可以找到现代 AMD CPU 中的 FMA4？3dNow呢？XOP？

          即使是 SSE 也无法保证，因为英特尔芯片从未实现过 SSE4a。

          AVX-512 尤其奇怪。Cannon 湖实现了 VBMI，但 Cooper 湖和 Cascade 湖却没有，只是在 Ice 湖、Tiger 湖和 Rocket 湖重新出现，然后在 Alder 湖消失，在 Sapphire Rapids 重新出现。BF16 出现在库珀湖，但在冰湖、老虎湖、火箭湖和桤木湖上消失，然后在蓝宝石激流上再次出现。

          回复

        2. >和 AVX-512，在 big-little 事件发生前，它们被关闭在桌面 P 核中，因为 E 核不支持 AVX-512。

          x86-64v4 需要 AVX-512。

          总之，他们彻底搞砸了。

          回复

      2. RISC-V 看了之后说：“看我的，我能做得更多”。

        此外，可以肯定的是，现在每个人都在使用 x86-x64-v2，其中包括 SSE4.2。几乎每个人都在使用 x86-x64-v3，其中包括 AVX2。实际上，支持的扩展主要有三个 “气泡”。英特尔曾试图用 AVX512 来搅局，但幸运的是，AMD 采取了更理智的做法，一切都趋于大致相同的 AVX512 支持子集。

        回复

        1. 不，RISC-V 已经考虑过这个问题，并决定将扩展的概念正式化，并通过适当的标准流程来实现，而不是任由制造商的产品和营销管道随心所欲。

          回复

          1. 然后将它们正规化，现在有超过 1 万亿种有效方法来创建符合标准的 RISC-V 内核。

            回复

            1. 不用担心，因为二进制软件的通用生态系统遵循 RVA 配置文件。

              微控制器/嵌入式可以随心所欲，因为供应商控制着整个堆栈，可以根据系统的需要构建固件映像。

              回复

              1. 嵌入式 RISC-V 的最大承诺是，供应商无需维护这样的工具链。如果必须维护工具链，那么使用专有内核就没有真正的好处。

                这也是他们使用 Arm 内核的一个重要原因。

                回复

                1. 当然，这就是工具链（gcc 和 llvm）支持指定使用哪些扩展的原因。

                  大多数人都会为配置文件构建，但嵌入式可以为他们使用的核心所具有的任何自定义扩展集构建，而这些扩展集并不一定是配置文件。

                  回复

                  1. +1. 考虑到为 ARM 构建时已经涉及了大量有关 FPU、MMU 等板卡特定编译器的参数，因此抱怨这一点很奇怪。如果有的话，选择扩展集会更简洁。d

                    回复

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注