为何push指令仅支持2字节和8字节操作数？技术咨询

为什么push仅支持64位（pushq）或16位（pushw）值？ #

这得从x86指令集的设计历史和架构规范说起：

• 早期16位x86处理器（比如8086）只有pushw指令，对应16位栈操作。
• 扩展到32位IA-32架构时，新增了pushl指令；但到64位x86-64时代，AMD做了指令集简化：默认栈操作宽度为64位，同时保留pushw用于兼容老旧代码，但不再支持32位pushl在64位模式下直接使用（如果要压入32位值，用pushq即可，CPU会自动将其零扩展为64位）。
• 另外，x86指令的编码规则里，push指令的操作数后缀和当前模式的默认栈宽度绑定，64位模式下没有给8位（pushb）预留编码空间，所以汇编器会抛出Error: invalid instruction suffix for 'push'的错误。

使用sub+mov替代push是否常见？属于反模式吗？ #

• 这不算反模式，甚至在不少场景下是常规操作：
  • 当需要一次性分配大块栈空间（比如给多个局部变量预留内存），直接用sub $N, %rsp再逐个mov写入，比多次push更高效，能减少指令数量。
  • 很多编译器在优化阶段会自动把连续的push指令转换成sub+mov组合，尤其是需要满足栈对齐要求时（比如x86-64下函数调用要求栈保持16字节对齐）。
• 不过如果只是压入单个值，push指令更简洁，而且CPU对push有专门的硬件优化（合并栈指针调整与内存写入操作），优先用push会更合适。

CPU对push的解释是否与sub+mov完全相同？ #

大部分场景下功能等价，但存在细微差异：

• 原子性：push是单条指令，栈指针调整和内存写入是原子操作；而sub+mov是两条指令，若在多线程环境下（虽然用户态栈通常是线程私有），其他线程修改栈指针可能导致中间状态不一致。
• 标志位影响：push指令不会修改任何CPU标志位；但sub指令会改变CF、ZF、SF等标志位，如果代码依赖标志位状态，就得留意这一点。
• 硬件效率：现代CPU对push/pop有专用的栈操作优化通路，执行效率可能比sub+mov略高一些。

你用GDB验证的例子完全符合预期：

push $5          ; 等价于 sub $8, %rsp; movq $5, (%rsp)
pushw $3         ; 等价于 sub $2, %rsp; movw $3, (%rsp)

GDB查看栈结构的输出：

x/5hd $rsp
0x7fffffffe426: 3 5 0 0 0

这是因为小端序存储的特性，pushw $3的16位值存在栈的低地址区域，pushq $5的64位值在高地址区域。

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