Assembly 为什么RV64为32位操作而不是64位操作引入了新的操作码

在浏览RISC-V规范时，我注意到64位版本与32位版本的不同之处在于

将寄存器扩展到64位

将指令更改为作用于整个64位范围

添加了执行32位操作的新指令

这使得RV32代码与RV64不兼容。 但是，如果64位版本是通过以下方式实现的：

将寄存器扩展到64位

将

ADD/SUB/SHL/。

重命名为

ADDW/SUBW/SHLW/。

，并使它们仅在32位带扩展符号的计算机上运行

添加新指令

Add/SUB/SHL/。

或

ADDD/SUBD/SHLD/。

以作用于整个64位

这将允许RV32程序也在RV64上运行。为了实现CPU，工作将保持不变，因为在这两种情况下都必须实现64位和32位指令，并且与规范相比，仅交换了64位和32位版本的操作码。（乘法指令除外。）

---

那么为什么RISC-V决定将新的操作码分配给32位操作而不是RV64中的64位操作呢？

RV64和RV32非常兼容。如果程序不依赖隐式模32位算法，并且所有地址都适合32位，那么机器代码可能是相同的。但是，将完整的RV32用户模式添加到RV64处理器非常容易

---

RV32的64位超集太复杂了。没有足够的操作码空间用于AUIPC、JAL、LOAD、STORE和BRANCH。如果有额外的扩展，情况会更糟

---

RV64中为数不多的32位指令主要用于过度使用模32位算术的程序。这是一个非常普遍的问题。但是，快速、可移植的代码应该避免使用它们。

这对于这种IP来说并不少见。这里没有真正的惊喜。可悲的现实是，如果芯片供应商来了，他们将进行定制，我们将面临一场与RV32不兼容的大规模兼容性噩梦，更不用说与RV64或它们彼此兼容了。这是假设当专利诉讼到来时，第一批必须抗争的人能够生存下来。可能（一个或多个）这些幸存者将是唯一制造基于risc-v的芯片的人。将risc-v的每个实现视为一个完全不同的处理器，这在很大程度上是您需要如何度过这一关的。例如，看看AARC32和AARC64。非常感谢。我不是那样看的。因此，基本上原因是，因为它无论如何都是不兼容的，所以通过尝试使事情变得复杂更简单。这是可以做到的，看看x86，它们使用相同的指令集从16位变为32位到64位，毫无疑问，在这一过程中添加了一些内容，但它们做到了，有人可能会说这是一条更痛苦的路径，也有人可能会说这是一条更少痛苦的路径。那么，如果程序依赖于模32位算术，那么RV64和RV32是不兼容的？如果简单地重命名32位函数，这些程序就不会不兼容。问题是为什么不简单地重命名它们？没有足够的操作码空间来添加额外的函数。事实上，对于接受某种类型的立即数的指令，操作码空间是有限的。他们也不想使用数据宽度标记寄存器。我想的更多的是缺少像OP这样的寄存器操作，因此我犯了错误。至于那个些，我想他们想要的是极简主义，以牺牲内存受限的程序在处理大量32位指针/伪指针/长度（如后缀数组或“riscv的x32”程序）时的性能为代价。内存受限的程序可以使用RV32用户模式。