Bobby Asked: 2024-12-17 14:51:08 +0800 CST2024-12-17 14:51:08 +0800 CST 2024-12-17 14:51:08 +0800 CST 在 Jonathan Barlett 的书中,图 6-1 中的底部的框应该是 %rax 而不是 %rbx 吗? 772 我一直在读一本名为《学习用汇编编程,Jonathan Barlett》的书。其中,我不理解图 6-1。 上下文:作者正在解释寄存器间接模式,使用mov (%rbx), %rax。 我怀疑底部的框应该标记%rax为 而不是%rbx。但我不是 100% 有信心。因为我是汇编新手。我是否遗漏了一些我必须知道的东西,或者作者是否犯了一个错误? assembly 1 个回答 Voted Best Answer Peter Cordes 2024-12-17T15:18:33+08:002024-12-17T15:18:33+08:00 对于mov (%rbx), %rax,加载结果写入 RAX。RBX 未经修改,仅可读取。 (与 ARM 不同,x86 没有任何后增量或预增量寻址模式可将任何内容写回到寻址模式寄存器。除了 和rep movsb等,但这些使用固定寄存器,而不是正常的 ModRM 寻址模式。) %rax底部框可能有意义,因为根据记忆,它是箭头的目的地。 但框外的文本已经覆盖了它。 底部框的一个可能的解释是来自内存对地址的响应%rbx。 其上方的文本说明了地址的分配位置。 就 CPU 的工作方式而言,如果保存该 qword 的缓存行在 L1d 缓存中尚未处于热状态,则处理此微操作的加载执行单元将不得不发出请求。如果它在 L2 缓存中也未命中,则必须通过内核和内存控制器之间的互连“核心外”发送请求。(假设典型的现代 x86 具有 3 级缓存,内部两级是每个内核私有的。) 因此从概念上讲,内存请求可能是一件大事,需要一些时间(或者对于重复访问同一条缓存行来说可能非常便宜)。对同一缓存行的其他加载也可以将自己附加到同一缓冲区以等待传入数据。无论如何,我认为绘制一个将请求和响应分开的图表是有意义的,所以我认为这就是正在发生的事情。 我不知道作者是否为这样的框图建立了惯例;如果是这样,那么解释的空间就更小了。 不久前,我花了几分钟浏览乔纳森的上一本书《从头开始编程》(免费,GFDL,使用 AT&T 语法介绍 i386,链接来自x86 标签 wiki以及其他有用资源),他确实谈到了一些关于真实 CPU 和真实操作系统如何运作的事情。
对于
mov (%rbx), %rax
,加载结果写入 RAX。RBX未经修改,仅可读取。
(与 ARM 不同,x86 没有任何后增量或预增量寻址模式可将任何内容写回到寻址模式寄存器。除了 和
rep movsb
等,但这些使用固定寄存器,而不是正常的 ModRM 寻址模式。)%rax
底部框可能有意义,因为根据记忆,它是箭头的目的地。但框外的文本已经覆盖了它。
底部框的一个可能的解释是来自内存对地址的响应
%rbx
。其上方的文本说明了地址的分配位置。
就 CPU 的工作方式而言,如果保存该 qword 的缓存行在 L1d 缓存中尚未处于热状态,则处理此微操作的加载执行单元将不得不发出请求。如果它在 L2 缓存中也未命中,则必须通过内核和内存控制器之间的互连“核心外”发送请求。(假设典型的现代 x86 具有 3 级缓存,内部两级是每个内核私有的。)
因此从概念上讲,内存请求可能是一件大事,需要一些时间(或者对于重复访问同一条缓存行来说可能非常便宜)。对同一缓存行的其他加载也可以将自己附加到同一缓冲区以等待传入数据。无论如何,我认为绘制一个将请求和响应分开的图表是有意义的,所以我认为这就是正在发生的事情。
我不知道作者是否为这样的框图建立了惯例;如果是这样,那么解释的空间就更小了。
不久前,我花了几分钟浏览乔纳森的上一本书《从头开始编程》(免费,GFDL,使用 AT&T 语法介绍 i386,链接来自x86 标签 wiki以及其他有用资源),他确实谈到了一些关于真实 CPU 和真实操作系统如何运作的事情。