assembly - 为什么调用和跳转指令使用相对于下一条指令的位移，而不是当前指令的位移？

Question

在从英特尔文档中摘录的下表中，我们发现操作码 E8 cw 和 E8 cd 的位移是相对于下一条指令的。

为什么是下一条指令？为什么位移不是相对于call指令本身？

Answer 1

TL:DR:无论如何，您在解码期间都会找到指令的结尾，并设置下一条指令的解码。 CPU 相对于当前指令的结束进行相对寻址是很正常的，尽管有些 CPU 会做出不同的选择，例如相对于下一条指令的结束(对于 ARM PC 相对内存寻址)。

参见Does Program Counter hold current address or the address of the next instruction?

<小时/>

x86 机器代码设计在 70 年代后期的 8086 中已经确定，除了在扩展 ISA 时重新设计的内容(例如 32/64 位 ModRM+SIB 寻址模式)。

原始的8086指令字节顺序解码(不一定是一次完整的指令)，并且对前缀字节数或总指令长度没有上限。

我认为 8086永远避免了保存指令起始地址的需要，即使出现异常也是如此。例如，在现代 x86 上#DE(除法异常)会推送错误指令的地址。但是on 8086 the exception frame has the address of the next instruction .

8086 甚至有一个“bug”(或已记录的设计缺陷)，其中在执行 cs rep movsb 期间到达的中断(例如)将最终前缀的地址推送为异常返回地址，使得 rep 字符串指令上的段重写在启用中断的情况下基本上不可用。 (因为执行将在没有 rep 或没有段覆盖的情况下恢复，无论您先放哪一个)。请参阅x86 Program Counter abstracted from microarchitecture?和评论。

<小时/>

当8086完成解码call指令时，它不知道它从哪里开始。它唯一的引用点是call指令的结尾。因此，如果他们想在硬件中进行优化(不在任何地方保留解码起始地址)，他们就不会这样做。甚至没有选择。尽管理论上他们可以使用 E8 调用操作码的地址(在任何前缀之后)作为 anchor ，但这可能需要额外的加法器或额外的硬件来单独记录。

Fetch/decode 已经必须在解码期间找到指令的结尾(同时确定它是 call 或 jmp)，因此指令结束/下一条指令的地址已经在内部可用。 call 甚至必须将该值压入堆栈作为返回地址。

流水线 RISC 或完全非流水线 CPU 也会使用该下一条指令地址从内存或 I-cache 中获取下一条指令。但实际上 8086 预取是异步到一个小的预取缓冲区中的。机器代码格式主要是在设计实现之前在纸上设计的，因此使事情与指令结尾相关的常见原因可能就是架构师所想到的。

对于许多 ISA 来说，创建相对于指令末尾的分支是一种常见的设计选择。

<小时/>

重申一下，我只谈论 8086(其内部与现代 x86 非常不同)的原因是它是第一代，并且理解它有助于解释一些机器代码设计决策。 (例如，为什么 x86 在单字节 xchg [e/r]ax, reg 上花费 8 个操作码:因为 8086 没有 movsx 或 2 操作数 imul ，并且需要或想要 AX 来处理很多事情。而且代码大小是性能的主要瓶颈。)

现代 x86 仅跟踪每条指令的地址，并在解码call rel32时使用它。没什么大不了的。 Why do x86 jump/call instructions use relative displacements instead of absolute destinations?