64位下mov $0x80000000,%eax会不会影响%rax的高32位？
我觉得不会影响，但是调试发现会，全部清零，什么道理？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我觉得不会影响，但是调试发现会，全部清零，什么道理？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（7）
AMD 第一卷上有
In general, byte and word operands are stored in the low 8 or 16
bits of GPRs without modifying their high 56 or 48 bits,
respectively. Doubleword operands, however, are normally
stored in the low 32 bits of GPRs and zero-extended to 64 bits.
mov eax, 0x80000000 --> b8 00 00 00 80
mov ebx, 0x80000000 --> c7 c3 00 00 00 80
-------------------------------------------------------------------
两种编码方式都做了"零扩展"
以前还真没认识到这个问题，要记录下来。
汗～
还真有这回事，连 AMD / Intel 的官方文档都没讲清楚
下面是我在 bochs 调试的情况：
复制代码
我分别用两种指令编码方式来测试 mov reg32, imm32 ，结果都是将高32位清 0 了，它们都作了 “零扩展”动作
AMD /Intel 的文档都没说出这个问题。
在指令mov $0x80000000,%eax之前，我设置了%rax的值，是-1,执行该指令后，再查看%rax的值，是0x80000000.说明高32位被冲掉了
不懂用 gdb
问题在哪？
那么下面的调试结果如何解释?
复制代码
是不会影响的