assembly - 对于可变长度指令，计算机如何知道正在获取的指令的长度？

Question

这个问题在这里已经有了答案:





Instruction decoding when instructions are length-variable

(4 个回答)


2年前关闭。




在并非所有指令长度都相同的体系结构中，计算机如何知道一条指令要读取多少？例如在 Intel IA-32 中有些指令是 4 字节，有些是 8 字节，那么它如何知道是读取 4 字节还是 8 字节呢？是不是机器开机时红色的第一条指令有一个已知的大小，并且每条指令都包含下一条指令的大小？

Answer 1

首先，处理器不需要知道要获取多少字节，它可以获取足够方便的字节数，足以为典型或平均指令长度提供目标吞吐量。任何额外的字节都可以放在缓冲区中，以便在下一组要解码的字节中使用。相对于支持的指令解码宽度，甚至与流水线后面部分的宽度，在取指的宽度和对齐方面存在折衷。获取比平均值更多的字节可以减少指令长度可变性和与所采取的控制流指令相关的有效获取带宽的影响。

(如果[预测的]目标直到下一次取指之后的一个周期才可用，则所采用的控制流指令可能会引入取指气泡，并减少与指令取指对齐的目标的有效取指带宽。例如，如果指令取指为 16-字节对齐——这对于高性能 x86 来说很常见——针对块中第 16 个 [最后一个] 字节的分支将导致有效地仅获取一个字节的代码，而其他 15 个字节将被丢弃。)

即使对于固定长度的指令，每个周期获取多条指令也会引入类似的问题。一些实现(例如，MIPS R10000)即使未对齐也会提取尽可能多的指令，只要指令组不跨越缓存线边界即可。 (我似乎记得一个 RISC 实现有两个 Icache 标签库，以允许获取跨越缓存块 - 但不是页面 - 边界。)其他实现(例如，POWER4)即使对于针对最后一个分支的分支也会获取对齐的代码块这样一个块中的指令。 (对于 POWER4，使用包含 8 条指令的 32 字节块，但每个周期最多 5 条指令可以通过解码。可以利用这种多余的提取宽度通过不执行提取的周期来节省能源，并为缓存块填充提供备用的 Icache 周期在一次未命中而只有一个读/写端口到 Icache 之后。)

对于每个周期解码多个指令，有两种有效的策略:并行推测解码或等待确定长度并使用该信息将指令流解析为单独的指令。对于像 IBM 的 zArchitecture(S/360 后代)这样的 ISA，16 位包中的长度由第一个包中的两个位决定，因此等待确定长度更有意义。 ( RISC V's 稍微复杂一点的长度指示机制对于非推测解码仍然是友好的。)对于像 microMIPS 或 Thumb2 这样的编码，它们只有两个长度可由主操作码确定，并且不同长度指令的编码本质上不同，使用非推测解码可能是首选，特别是考虑到可能的窄解码和强调能源效率，尽管只有两个长度，一些推测在小解码宽度下可能是合理的。

对于 x86，AMD 用来避免过度使用解码能量的一种策略是在指令缓存中使用标记位，指示哪个字节结束指令。有了这样的标记位，很容易找到每条指令的开始。这种技术的缺点是它增加了指令缓存未命中的延迟(指令必须被预解码)，并且它仍然需要解码器检查长度是否正确(例如，如果跳转到以前的内容)指令的中间)。

英特尔似乎更喜欢推测性并行解码方法。由于要解码的块中前一条指令的长度仅在适度延迟后可用，因此第二个和后面的解码器可能不需要完全解码所有起始点的指令。

由于 x86 指令可能相对复杂，因此通常还存在解码模板约束，并且至少有一个较早的设计限制了在保持完整解码带宽的同时可以使用的前缀数量。例如，Haswell 将解码的第二到第四条指令限制为仅产生一个微操作，而第一条指令最多可以解码为四个微操作(使用微代码引擎的微操作序列更长)。基本上，这是对常见情况(相对简单的指令)的优化，以牺牲不太常见的情况为代价。

在最近的面向性能的 x86 设计中，英特尔使用了 µop 缓存，该缓存以解码格式存储指令，避免模板和获取宽度限制并减少与解码相关的能源使用。