Nios II汇编函数参数寄存器r4-r7存储的是实际值还是参数地址？

针对你提到的int add(int x, int y)示例，调用时r4寄存器中存储的是参数x的实际值，而非x对应的内存地址。

规则设计的底层逻辑 #

• Nios II 是典型的RISC架构，寄存器传参的核心设计目标是降低函数调用的访存开销：如果r4/r5这类寄存器里存的是参数地址，函数入口处需要额外发起一次内存读取才能拿到实际参数，完全违背了寄存器传参的设计初衷。
• 按照Nios II的硬件调用约定，长度不超过32位的基本类型参数（int、char、枚举、指针、32位浮点数等），会按照从左到右的顺序依次存入固定寄存器：
  • 第1个整数/指针类参数 → r4
  • 第2个整数/指针类参数 → r5
  • 第3个整数/指针类参数 → r6
  • 第4个整数/指针类参数 → r7
  • 超过4个的后续参数会通过栈传递，依然直接存参数实际值

示例的完整调用流程演示 #

以C语句int res = add(10, 20);为例，对应的汇编实现完全不需要读写x、y的内存地址：

1. 调用前的参数装载指令：

   movi r4, 10   // 直接把x的实际值10写入r4
   movi r5, 20   // 直接把y的实际值20写入r5
   call add      // 跳转到add函数入口
   

2. add函数内部的实现完全基于寄存器值运算：

   add:
       add r2, r4, r5  // 直接取r4、r5中存的实际值相加，结果存入r2（Nios II默认返回值寄存器）
       ret             // 函数返回
   

容易混淆的特殊场景 #

只有以下两类情况，寄存器中存储的内容会看起来是“地址”，需要和普通参数传参场景区分：

• 当函数参数本身就是指针类型时：比如函数定义为int read_val(int* ptr)，此时r4中存储的是指针变量本身的值（也就是指向目标内存的地址），这是参数类型决定的，不是普通值参数的传参规则。
• 当参数长度超过32位寄存器宽度时：比如传入64位的long long类型参数，会用两个相邻寄存器拼接存储参数的实际值，依然不是存参数的地址。

内容的提问来源于stack exchange，提问作者Anis AIT