RISC-V64裸机C99环境下常量加载汇编约束问题咨询

我在裸机C99环境下开发，使用以下RISC-V64代码：

#define FOO 0x234567894567ULL
extern void someFunction(void);

void example(void) __attribute__((naked));
void
example(void)
{
  __asm__ volatile(
    "   li  t0, %[value]   \t\n"
    "   ecall              \t\n"
    : /* no output args */
    : [value]  "i"  ((uint64_t) FOO)
    : "t0"
  );
}

这段代码在Godbolt的gcc trunk、gcc-8.2及gcc-8.5.0中可正常编译为预期汇编，但使用SiFive GCC 8.3.0-2019.08.0工具链时，会报asm operand 1 probably doesn't match constraints [-Werror]错误。

若将输入操作数约束从"i"改为"r"，Godbolt的三个工具链可正常生成通过中间寄存器加载常量的汇编，但SiFive工具链的汇编器会报错Error: illegal operands li t0,a5'`。

仅当将li伪指令改为mv伪指令时，SiFive工具链才可正常编译，但会占用额外寄存器。

现咨询：

1. 将常量（及地址）加载到寄存器的推荐方式，是否有RISC-V专用操作数约束？
2. 为何SiFive工具链与同版本Godbolt工具链表现不同？

注：代码用于异常/中断处理，对执行速度要求极高。

回答 #

1. 常量/地址加载的推荐方式与RISC-V专用约束 #

• 最优写法原则：优先依赖编译器自动生成加载代码，避免手动硬编码指令——编译器会根据常量大小和指令集特性选择最快的加载组合（比如lui+addi或单条li伪指令）。如果必须手写内联汇编，需匹配正确的约束和指令：
  • 对于可通过li伪指令直接加载的常量，使用"i"或"n"约束（"n"代表编译器可处理的任意整数常量，兼容性更强）配合li指令。
  • 如果用"r"约束（寄存器传递常量），必须使用mv指令而非li——因为li是加载立即数的伪指令，不支持寄存器作为源操作数。
• RISC-V专用约束：GCC针对RISC-V指令集提供了几个专用约束：
  • I：适配12位有符号立即数（如addi指令的操作数范围）
  • J：适配20位跳转立即数（如j/jal指令）
  • K：适配无符号12位立即数（如lw/sw的偏移量）
  • N：适配5位移位立即数（如srli/slli的移位量）
• 性能优化建议：异常/中断场景需尽量减少寄存器占用，建议直接在C代码中赋值常量给寄存器（如register uint64_t t0 __asm__("t0") = FOO;），再通过内联汇编引用该寄存器，让编译器自动生成最优加载指令，避免手动干预导致的冗余操作。

2. SiFive工具链与Godbolt同版本工具链的差异原因 #

• 组件版本不匹配：SiFive工具链标注的GCC版本为8.3.0，但实际集成的binutils（汇编器as）可能与Godbolt使用的标准GCC工具链不同。旧版SiFive binutils对li伪指令的兼容性处理存在bug，不允许li接受寄存器作为操作数，而标准GCC的binutils会自动将这种情况转为mv指令。
• 定制化修改差异：SiFive为适配自家硬件，会对上游GCC/binutils进行定制修改，比如对指令集扩展的默认支持、约束检查逻辑的调整，导致与标准GCC的行为不一致。你使用的2019.08.0版本SiFive GCC可能未合并上游GCC 8.5.0中修复的RISC-V立即数约束相关bug，而Godbolt的gcc-8.5.0包含这些修复。
• 默认编译选项差异：Godbolt的GCC默认启用的优化或兼容性选项，与SiFive工具链的默认配置不同——比如SiFive工具链可能默认启用更严格的指令集校验，导致64位常量无法通过"i"约束的检查，而标准GCC对约束的宽松度更高。

内容的提问来源于stack exchange，提问作者Lance E.T. Compte