ARM Linux：为什么Linux希望寄存器r0设置为零

ARM Linux引导手册规定寄存器r0应为零。为什么寄存器r0应该是zer0

---

我浏览了arch/arm/kernel/head.S，但找不到原因。

一致性和效率。由于将寄存器设置为零是一种常见操作，并且ARM通常用于受限环境，因此代码密度可能会有所提高。将寄存器设置为立即数的指令编码比将寄存器设置为另一个寄存器的值的指令编码长。这在实践中是否会产生很大的不同是另一个问题。

虽然我在Linux内核邮件列表或Linux源代码中找不到任何证实这一点的参考，但我推测该值将被用作ABI版本，用于将来验证ABI

内核的未来版本可能希望修改从引导加载程序传入的参数：可能某个新CPU功能需要一个新参数，或者需要稍微调整一个现有参数

当从旧的引导加载程序引导新内核时，这会带来一个严重的问题：内核如何知道传入了哪些参数？我们可以尝试强制新内核只能用新的引导加载程序引导，但这会在过渡期间引起很多头痛。（引导加载程序是由Linux内核团队之外的人编写的；并且经常深入到硬件中，在某些情况下防止它们容易升级。）

---

更好的解决方案是将寄存器

r0

保留为ABI版本。目前，我们坚持认为

r0

始终为0。如果ABI发生变化，

r0

可能会增加一个。随后，未来的内核可以检查

r0

，以确定引导它的ABI版本，从而确定如何解释其他寄存器中的值。

ARM没有一个有效的带自操作的XOR？不过，我还不清楚。你能详细解释一下吗。A） 如果寄存器没有设置为零，会有什么不同。b） 有15个寄存器，但为什么只有r0？好吧，如果代码假设r0为零而不是，那么程序的行为将是未定义的。我没有写ABI规范。我不认为它有任何架构上的必要性，但一旦它建立起来，你就会被传统束缚住。布雷特，谢谢你的回答。实际上，我在“arch/arm/kernel/head.S”中找不到检查寄存器值的任何地方（ASFAIK）。根据EVM名称检查寄存器r1，但与r0不同。而且，既然它总是零，为什么不能在启动代码中设置它呢？不需要检查它是否被依赖。如果有人编写了与您的代码接口的代码，并期望R0为0，而您将其设置为非0，那么就会出现问题。我不知道你所说的“为什么不能在启动代码中设置它”是什么意思。

CPU register settings
    r0 = 0.
    r1 = machine type number discovered in (3) above.
    r2 = physical address of tagged list in system RAM.