Assembly 你是零吗？

我正在使用一些为MIPS R3000A芯片编写的代码，有很多函数对我来说似乎完全无用。。。我想核实他们是否按照我的想法行事

FNC_0000e3bc:                         # 
    jr      ra                        # 0000e3bc:03e00008   
    addiu       zero, zero, 0x0006    # 0000e3c0:24000006   
FNC_0000e3c4:                         # 
    jr      ra                        # 0000e3c4:03e00008   
    addiu       zero, zero, 0x0007    # 0000e3c8:24000007   

我把这两个读作“返回，在延迟槽中什么也不做”，对吗？ 如果是这种情况，是否有任何理由说明

addiu

不仅仅是

nop

？或者为什么要调用这些函数

我觉得奇怪的是，这些函数的加法数从4到0x21不等。让我想他们会做些什么，但我不知道他们会怎么做

无论哪种方式，谢谢您的任何意见

---

编辑：好吧，我将采用“调试器遗留问题”的想法。似乎它们都被称为独一无二的，所以很适合。这是为了声音播放，所以我真的怀疑他们在做操作码检查（不知道，但我怀疑）。

这是在什么平台上？这很奇怪，但它确实相当于

nop

，是的，我怀疑调试器或代码的其他部分在运行时使用它在可执行文件中做了一些奇怪的事情（但在不了解平台的情况下很难说）。

可能是针对某些调试器类型的活动，这样他们就能知道他们在哪里？也许程序的某个部分会检查操作码。addiu zero，zero，0x0006是

0010 0100 0000 0110

，具体来说，它是为PlayStation 2的IOP处理器编写的声音库。我确实检查过它是否是某种时髦的系统调用之类的东西，但从我看来不是。延迟槽中不能有

syscall

，所以肯定不是这样。关于PS2库很有趣，因为我很好奇这是否与控制台相关（我是通过PS1开发在MIPS上“长大的”）。你在上面贴的是自动生成的反汇编吗？或者这是库的实际源代码？如果是后者，那么也许开发人员使用它是为了方便地找到部分代码？它是编译的，并通过ps2dis进行反汇编。我假设它最初是C，因为同一个游戏中的其他可执行文件都是用C编写的（并且它使用了printf的一个版本）。而且，不管它值多少钱，它可能是用2002年左右的gcc版本编译的。（作为debug硬编码的日期是2002年4月26日）您甚至可以从汇编中调用

printf

，因此这并不能证明它是基于C的。在没有看到反汇编的其余部分的情况下，根据我的经验很难说它是C还是纯asm，但我仍然认为那些

addiu

s是出于某种文档或参考目的，因为MIPS上典型的

nop

（没有明确的

nop

指令）是

sll零，零，0

。这就是我要说的，它们与调试器相关。不管怎样，这都回答了我的问题：这些函数完全没有任何作用。谢谢你的帮助！