分支预测如何与指令指针交互 [英] How does branch prediction interact with the instruction pointer
问题描述
据我了解，在处理器流水线的开头，提取后分支预测器会更新指令指针（指向要执行的下一条指令的地址），以便随后可以在该地址上获取该新地址。
但是，如果在管道的早期修改了指令指针，这不会影响当前可能依赖于旧指令的执行阶段中的指令指令指针值？例如，当执行调用时，当前EIP需要被推入堆栈，但是在分支预测期间更新指令指针时，这不会受到影响吗？
您似乎假设整个CPU内核仅使用一个物理EIP寄存器。
那是行不通的，因为每条可能会发生异常的指令都需要知道自己的地址。或者，当外部中断到达时，CPU可以在收到任何指令后决定服务该中断，从而使该中断成为体系结构的EIP。在长模式（x86-64）中，还存在相对于RIP的寻址模式，因此 call 不是唯一需要当前程序计数器作为数据的指令。 / p>
一个简单的流水线CPU可能在每个流水线阶段都有一个EIP。
现代超标量输出-有序的x86将EIP（或RIP）与每个运行中的指令（或也许每个uop 相关联；但是多uop指令的所有uop都相互关联，因此指令不能部分退出。）
与体系结构状态的其他部分（例如EFLAGS，EAX等）不同，该值在解码后是静态已知的。实际上甚至比立即值还早；在预解码阶段（或在L1i缓存中标记）检测到指令边界，以便可以将多个指令并行地馈送到多个解码器。
早期的获取/解码阶段可能只跟踪16字节或32字节提取块的地址，但是在解码之后，我假定内部uop表示中有一个地址字段。对于非分支指令，它可能仅与前一个（节省空间）相差很小，因此，如果需要，可以对其进行计算，但是我们在此处深入介绍了实现细节。乱序执行会保持以程序顺序运行的指令的错觉，它们会按顺序发布和退出（输入/保留内核的乱序执行部分）。
相关： x86寄存器：MBR / MDR和指令寄存器根据玩具CPU的情况做出了类似的错误假设。也没有保存机器代码字节的当前指令寄存器。
分支预测必须在块被执行之前起作用，有关更多信息，请参见我的答案。甚至解码。也就是说，假设我们刚刚在地址abc处获取了一个块，则需要预测接下来要获取的块。也就是说，预测必须预测将要并行解码的16字节指令块中是否存在跳转。
It's my understanding that at the beginning of a processor's pipeline, the instruction pointer (which points to the address of the next instruction to execute) is updated by the branch predictor after fetching, so that this new address can then be fetched on the next cycle.
However, if the instruction pointer is modified early on in the pipeline, wouldn't this affect instructions currently in the execute phase that might rely on the old instruction pointer value? For instance, when doing a call the current EIP needs to be pushed into the stack, but wouldn't this be affected when the instruction pointer is updated during branch prediction?
You seem to be assuming that there's only one physical EIP register that's used by the whole CPU core.
That doesn't work because every instruction that could take an exception needs to know its own address. Or when an external interrupt arrives, the CPU could decide to service the interrupt after any instruction, making that one the architectural EIP. In long mode (x86-64), there are also RIP-relative addressing modes, so call isn't the only instruction that needs the current program-counter as data.
A simple pipelined CPU might have an EIP for each pipeline stage.
A modern superscalar out-of-order x86 associates an EIP (or RIP) with each in-flight instruction (or maybe each uop; but multi-uop instructions have all their uops associated with each other so an instruction can't partially retire.)
Unlike other parts of the architectural state (e.g. EFLAGS, EAX, etc.) the value is statically known after decode. Actually even earlier than immediate values; instruction boundaries are detected in a pre-decode stage (or marked in L1i cache) so that multiple instructions can be fed to multiple decoders in parallel.
The early fetch/decode stage might just track addresses of 16-byte or 32-byte fetch blocks, but after decode I assume there's an address field in the internal uop representation. It might just be a small offset from the previous (to save space) for non-branch instructions, so if it's ever needed it can be calculated, but we're deep into implementation details here. Out-of-order execution maintains the illusion of instructions running in program-order, and they do issue and retire in-order (enter/leave the out-of-order execution part of the core).
Related: x86 registers: MBR/MDR and instruction registers makes a similar wrong assumption based on looking at toy CPUs. There is no "current instruction" register holding the machine code bytes either. See more links in my answer there for more about OoO / pipelined CPUs.
Branch prediction has to work before a block is even decoded. i.e. given that we just fetched a block at address abc, we need to predict what block to fetch next. i.e. prediction has to predict the existence of jumps in a 16-byte block of instructions that will be decoded in parallel.
Related: Why did Intel change the static branch prediction mechanism over these years?
这篇关于分支预测如何与指令指针交互的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
