[RISCV] 一些关于-march、-mabi 和-mtune的发现

The only build-time differences between the various RISC-V toolchain configure options are what the defaults are, all toolchains support all targets. C libraries must be built to target each ISA and ABI variant you’re interested in, you can see an example of how we’re doing that in riscv-gnu-toolchain.

各种 RISC-V 工具链配置选项之间唯一的构建时差异是默认值，所有工具链都支持所有目标。 必须构建 C 库来针对您感兴趣的每个 ISA 和 ABI 变体，您可以在 riscv-gnu-toolchain 中查看我们如何做到这一点的示例。

-m32/-m64 are gone from RISC-V gcc/binutils, they’re unnecessary because of -march. Whatever documentation they’re in is wrong, if you can give me a pointer I’ll fix it.

-m32/-m64 已从 RISC-V gcc/binutils 中消失，由于 -march，它们不再需要。 无论它们所在的文档是错误的，如果您能给我一个指示，我会修复它。

-march=ISA controls the targeted ISA, using a lower case RISC-V ISA string name (for example, “rv64ic”). This controls what instructions the compiler generates and the assembler accepts. You’re allowed to link together to objects that were produced with different “-march” values.

-march=ISA 使用小写 RISC-V ISA 字符串名称（例如“rv64ic”）控制目标 ISA。 这控制编译器生成和汇编器接受的指令。 您可以将使用不同“-march”值生成的对象链接在一起。

-mabi=ABI controls the targeted ABI, using an ABI string (for example “ilp32d”). ABI strings look like the standard way to describe ABIs (ie ilp32 means Integer, Long, and Pointer are 32 bits; while lp64 means Long and Pointer are 64-bits) but with an addition letter describing the largest supported floating-point mode (f, d, or q). ABI strings control how C types exist in memory, and therefor it is illegal to link together two objects of different ABIs.

-mabi=ABI 使用 ABI 字符串（例如“ilp32d”）控制目标 ABI。 ABI 字符串看起来像描述 ABI 的标准方式（即“ilp32”表示整数、长整型和指针是 32 位；而“lp64”表示长整型和指针是 64 位），但带有一个附加字母来描述支持的最大浮点数 点模式（f、d 或 q）。 ABI 字符串控制 C 类型在内存中的存在方式，因此将不同 ABI 的两个对象链接在一起是非法的。

-mtune=UARCH controls performance-sensitive code generation for a target microarchitecture, but doesn’t have any correctness impact. Right now I think we only support generic, but there might still be a rocket tuning in there as well.

-mtune=UARCH 控制目标微架构的性能敏感代码生成，但不会产生任何正确性影响。 现在我认为我们只支持“通用”，但那里可能仍然有“火箭”调整。

At least some of the problems here are due to march/mabi mismatches – it looks like you’re requested “-mabi=lp64d” code with “-march=rv32im”. This is impossible, as the “lp64d” ABI says that 64-bit integer/pointer types are passed in X registers (which is impossible when xlen=32), and that single+double are passed in F registers (which is impossible when flen=0).

至少这里的一些问题是由于 March/mabi 不匹配造成的——看起来你需要“-mabi=lp64d”代码和“-march=rv32im”。 这是不可能的，因为“lp64d”ABI 表示 64 位整数/指针类型在 X 寄存器中传递（当 xlen=32 时这是不可能的），而 single+double 在 F 寄存器中传递（当 flen 时这是不可能的） =0）。

---

The reason it’s done this way is that “hard float” and “soft float” are a bit ambiguous: does the “hard” refer to the ABI constraint or the instruction constraint? There’s actually four options for floating-point code generation:

这样做的原因是“硬浮点”和“软浮点”有点含糊：“硬”是指ABI约束还是指令约束？ 实际上有四种浮点代码生成选项：

• “-march=rv64id -mabi=lp64d”: FP types are passed in F registers, and FP operations are done using explicit floating-point instructions. This coresponds to ARM’s “-mfloat-abi=hard”.

“-march=rv64id -mabi=lp64d”：FP类型在F寄存器中传递，FP操作使用显式浮点指令完成。 这对应于 ARM 的“-mfloat-abi=hard”。

• “-march=rv64i -mabi=lp64d”: FP types are passed in F registers, but FP operations are done using a software floating-point implementation. This doesn’t make any sense, as on RISC-V you must implement the floating-point instructions if you have F registers. Thus the toolchain explicitly disallows this option – though we could always allow it in the future, if someone has a compelling reason to do so.

“-march=rv64i -mabi=lp64d”：FP 类型在 F 寄存器中传递，但 FP 操作是使用软件浮点实现完成的。 这没有任何意义，因为在 RISC-V 上，如果有 F 寄存器，则必须实现浮点指令。 因此，工具链明确不允许这个选项——尽管我们将来总是可以允许它，如果有人有令人信服的理由这样做的话。

• “-march=rv64id -mabi=lp64”: FP types are passed in X registers, but FP operations are done using explicit floating-point instructions. This cooresponds to ARM’s “-mfloat-abi=softfp”, a silly name.

• “-march=rv64id -mabi=lp64”：FP 类型在 X 寄存器中传递，但 FP 操作是使用显式浮点指令完成的。 这对应于 ARM 的“-mfloat-abi=softfp”，一个愚蠢的名字。

• “-march=rv64i -mabi=lp64”: FP types are passed in X registers, and FP operations are done using a software floating-point implementation. This cooresponds to ARM’s “-mfloat-abi=soft”.

• “-march=rv64i -mabi=lp64”：FP 类型在 X 寄存器中传递，并且 FP 操作使用软件浮点实现来完成。 这对应于 ARM 的“-mfloat-abi=soft”。

You’re more than welcome to implement whatever microarchitecture you want, if it executes all the RISC-V instructions then it’ll run code our toolchain generates. Specifically as to your “CPU that use the integer register file to feed the FPU” seems possible: if you’re building a machine with register renaming that shares the physical register file between X and F registers then you could perform some renaming tricks to make fmv.x.d and friends just copy physical register IDs instead of copying data. Optimizing a high-performance machine for “-march=rv64i -mabi=lp64d” performance seems like a bad place to spend your time, but in this case it might come for free from eliding all other copy instructions so maybe it’s worth it.

我们非常欢迎您实现您想要的任何微架构，如果它执行所有 RISC-V 指令，那么它将运行我们的工具链生成的代码。 具体来说，您的“使用整数寄存器文件来馈送 FPU 的 CPU”似乎是可能的：如果您正在构建一台具有寄存器重命名功能的机器，该机器在 X 和 F 寄存器之间共享物理寄存器文件，那么您可以执行一些重命名技巧来使 fmv.x.d 和朋友只是复制物理寄存器 ID，而不是复制数据。 优化高性能机器以获得“-march=rv64i -mabi=lp64d”性能似乎是一个不好的地方，但在这种情况下，它可能会免费消除所有其他复制指令，所以也许这是值得的。