X86 指令解码队列（IDQ）中的微操作是如何安排的？

我一直在想一件事，但首先，一个假设是，由宏op生成的所有μop都可以具有与宏op相同的

rip

（我很确定IQ会为每个IFETCH块设置一个

rip

，解码器可以根据长度信息轻松地将

rip

+宏op的偏移量转换为宏op的

rip

）。IDQ是SnB上每个逻辑核的8行32字节（在最近的微体系结构中可能是64字节，但我不确定），这就引出了IDQ中μops格式的问题——每个IDQ行是否有一个地址，

jmp

指令是否会导致一个新行启动，类似于μopcache；根据优化手册的解释，一个32字节对齐的区域可以跨越3种方式，但最后一种方式必须以

j结尾mp

大概是为了通过将管道引导到下一个指令窗口（也可能跳回μop缓存或可能必须启动传统解码管道）来重新初始化下一个指令窗口的提取。如果IDQ具有相同的结构，它将允许将μop缓存方式轻松移动到IDQ（因此我确实觉得IDQ可以在每一行的开头有一个地址，而不是每一条指令，因为如果行上的指令具有连续的

rip

s，并且分支、返回等后的指令将位于新行上，则不需要这样做）。它还允许LSD更有效地锁定和检测循环，因为它只需扫描行开头的8个地址，以检查它是否与

jmp

地址相同。但是，我同样不确定LSD是如何精确实现的；源代码似乎将28μops的值作为最大循环可以检测到

还有堆栈引擎的复杂性以及它如何放置同步操作；阅读堆栈引擎上microarchitecture.pdf中Agner fog的部分可以看出，同步μop是在

mov

或

add

之前插入的，这会导致它需要

rsp

同步，因此它必须进行同步在原始

mov

或

add

之前存在

ret

的情况下，获取该指令的

rip

（因此可以将其与

rsp

进行比较，以检查任何端口处理

ret

，BEU？（*）上的RSB预测。我还建议堆栈引擎与解码器一起工作，这样它就可以在解码器插入的同时插入，而不必在以后为了插入它而沿着指令移动。同步op上还必须有一个位指示，以通知分配器在计算rips。它也可以在同步操作后为指令启动新行，但这可能看起来很昂贵

阻止这种逻辑死机的原因很简单，就是指令的

rip

无法从行上的μop的字节偏移量与行开头的地址计算出来，因为宏ops的长度与μops的长度不同。这可以通过让每个IDQ行对应来解决每个宏操作一个（任何同步操作都附加到行的末尾，即一行上的

mov

+同步跳和我前面提到的

ret

，在下面的行地形上，在每行的开头都有一个

rip

），我想这似乎是浪费。我能想到的唯一替代方法是为每个看起来很混乱的宏操作内联标记地址

关于如何实现这一点，是否有人需要补充或纠正

---

（*）这确实与如何处理分支预测失误的问题有关，例如，当预测执行的分支指令分配给RS时，其中一个参数可能是指令的ROB条目的

rip

，因为它可以在预测失误时引导管道。当分配

ret

时，其中一个参数可能是参数必须是uop后面的ROB条目，另一个参数是

rsp

，以便与之进行比较。

IDQ大小以uop为单位，而不是字节。例如，Skylake有一个64 uop IDQ（为每个线程复制，因此在SMT模式下每个线程都有自己的64 uop队列）。您从哪里得到这个“8行32字节”的数据？但最后一条路径必须以

jmp

结尾。不，你可以向后看。任何

jmp

都将以uop缓存“路径”（也称为行）结尾。但行也可以简单地结束，因为下一条x86指令的开始位于32字节边界的另一侧。（IIRC，一条跨越32或64字节边界的指令根据其第一个字节的位置进入uop缓存线。）28个uop的LSD大小来自SnB/IvB上的IDQ大小。实际上，IDQ可能是一个带头和尾的循环缓冲区（实际上不是将所有数据复制到下一个条目）。LSD只是“锁定”当跳回IDQ中的uop时，队列中的uop被识别（并满足其他启发式）。因此，如果微码更新未禁用LSD，SKL的LSD限制为64 uop。单线程模式（非HT）下的HSW应具有56个条目的LSD。请参阅。