macOS NASM x86_64中ret与_exit差异及寄存器使用问题

问题1：ret与_exit运行差异的根因 #

核心原因是违反了x86_64 macOS遵循的System V AMD64调用约定，未保存恢复被调用者保存（callee-saved）寄存器：

• System V ABI明确规定：rbx、rbp、r12~r15属于被调用者保存寄存器，被调用函数如果要修改这些寄存器，必须在函数入口把原始值压栈保存，函数返回前恢复原始值，保证调用者看到这些寄存器的值和调用前完全一致。
• 你的_printy函数里修改了rbx、r12、r15三个寄存器，但函数入口只保存了rbp，没有保存这三个寄存器的值，返回时这三个寄存器已经被改成循环计数、数组指针之类的临时值，不是调用_printy之前的原始值。
• 调用_exit能正常运行的原因：_exit是系统调用封装，会直接触发内核终止进程，根本不会返回给上层调用者（也就是启动你程序的dyld动态链接器），被改坏的寄存器永远不会被dyld用到，自然不会触发崩溃。
• 用ret从_main返回时崩溃的原因：_main是dyld调用的，dyld在_main返回后会继续执行自身的清理、退出流程，这部分代码依赖rbx等被调用者保存寄存器的原始值。你看崩溃点的指令mov rax, qword ptr [rbx + 0x8]，就是dyld把rbx当指针用，但此时rbx已经被你的代码改成了数组循环的最终计数值，是个非法内存地址，自然触发EXC_BAD_ACCESS。

修复方法很简单：在_printy的入口push需要修改的被调用者保存寄存器，返回前逆序pop恢复即可，参考代码如下：

_printy:
    push rbp
    push rbx  ; 保存用到的callee-saved寄存器
    push r12
    push r15
    mov rbp, rsp
    sub rsp, 16
    ; 原有逻辑不变
.done:
    leave
    pop r15 ; 逆序恢复寄存器
    pop r12
    pop rbx
    ret

问题2：寄存器位宽选择的相关说明 #

32位寄存器操作的性能与正确性 #

对于你处理32位int数组的场景，用32位寄存器esi才是正确写法，比错误使用64位寄存器rsi更好：

• 你之前写的mov rsi, [r12 + rbx * 4]是8字节内存加载，会越界读取int元素后面4字节的无关内存，属于未定义行为，只是因为printf处理%d时只取低32位，才暂时没暴露问题。
• 从性能上看，x86_64架构规定写入32位通用寄存器时，CPU会自动把寄存器高32位零扩展，这个操作是硬件层面免费完成的，和写入64位寄存器没有任何延迟、吞吐量差异。而且32位寄存器操作的指令编码更短（多数场景不需要额外REX前缀），能提升指令缓存效率，实际运行有微小优势。
• 你用ebx做循环计数、r15d存数组长度的写法完全正确，不会有任何问题。

movsx符号扩展加载的差异 #

效果和性能要分场景判断：

• 如果你的数组元素是无符号int：不需要符号扩展，直接用mov esi, [r12 + rbx*4]零扩展加载就符合ABI要求，是正确写法。
• 如果你的数组元素是有符号int：按照System V ABI要求，传参时需要把32位有符号值符号扩展到64位，这时候必须用movsx rsi, dword [r12 + rbx*4]做符号扩展加载，否则遇到负数时会因为高32位为0不符合传参规则，属于未定义行为。
• 性能上，符号扩展加载movsx和普通mov加载在所有现代x86_64处理器上都是单周期指令，延迟、吞吐量完全一致，没有性能损失。

内容的提问来源于stack exchange，提问作者great coconut