为什么 INC 和 DEC 指令*不*影响进位标志 (CF)？

Question

为什么x86指令INC（递增）和DEC（递减）不影响FLAGSREGISTER中的CF（进位标志）？

Answer 1

要了解为什么您可能需要记住当前具有 32 位和 64 位值的“x86”CPU 开始使用的 8 位机器更加有限，可以追溯到 Intel 8008。（我早在 1973 年就在这个世界上编码，我还记得（呃）它！）。

在那个世界里，寄存器既珍贵又小。您需要INC/DEC 用于各种目的，最常见的是循环控制。许多循环涉及执行“多精度算术”（例如，16 位或更多！）通过让INC/DEC 设置零标志（Z），您可以使用它们很好地控制循环；通过坚持循环控制指令不更改进位标志 (CF)，进位在循环迭代中得以保留，您可以实现多精度运算，而无需编写大量代码来记住进位状态。

一旦你习惯了丑陋的指令集，这效果很好。

在具有更大字数的更现代的机器上，你不需要这么多，所以INC 和DEC 在语义上可能等同于ADD ...,1 等等。这实际上是我的当我需要携带套装时使用：-}

大多数情况下，我现在远离INC 和DEC，因为它们会进行部分条件代码更新，这可能会导致管道中出现有趣的停顿，而ADD/SUB 不会。所以在不重要的地方（大多数地方），我使用ADD/SUB 来避免摊位。我只在保持代码小问题时才使用INC/DEC，例如，在缓存行中，一两条指令的大小会产生足够的差异。这可能是毫无意义的 nano[字面意思！]-优化，但我的编码习惯相当老派。

我的解释告诉我们为什么 INC/DEC 设置零标志 (Z)。对于INC/DEC 设置符号（和奇偶校验标志）的原因，我没有特别令人信服的解释。

编辑 2016 年 4 月：似乎在现代 x86 上可以更好地处理失速问题。见INC instruction vs ADD 1: Does it matter?

Answer 2

当你有 zero 标志由 inc/dec 设置时为什么 sign 的问题最好用问题来解决：你宁愿没有选项 一个 ?

a) for (n=7;n>=0;n--)   // translates to   `dec + jns`
b) for (n=8;n>0;n--)    // translates to   `dec + jnz`

正如Ira Baxter 已经澄清的那样，进位标志用于很多算法——不仅是多精度算术，还用于单色/cga/EGA 时代的位图处理： 这会将 80 像素宽的行向右移动一个像素...

        mov cx, 10
begin:  lodsb
        rcr al,1   // this is rotate though carry:
        stosb      // for the algorithm to work, carry must not be destroyed
        LOOP begin //

但是：为什么是平价？

我相信答案是为什么不。该指令集来自 70 年代后期，当时晶体管稀缺。拒绝为某些特定指令计算奇偶校验标志没有任何意义，只会增加 CPU 的复杂性。

Answer 3

1. inc 和 dec 指令通常用于维护迭代或循环计数。使用 32 位，迭代次数可高达 4,294,967,295。这个数字对于大多数应用来说已经足够大了。如果我们需要比这更大的计数怎么办？我们必须使用 add 而不是 inc 吗？这就引出了第二个也是主要原因。

2. 进位标志检测到的条件也可以用零标志检测。为什么？因为 inc 和 dec 仅将数字更改 1。例如，假设 ECX 寄存器已达到其最大值 4,294,967,295 (FFFFFFFFH)。如果我们再执行

                    inc ECX
   

   我们通常期望进位标志设置为 1。但是，我们可以通过注意 ECX = 0 来检测这种情况，这会设置零标志。因此，设置进位标志对于这些指令来说确实是多余的。

Answer 4

因为不需要影响。检查零标志就足够了。 因此，在 inc 和 dec 指令之后，进位标志保持不变，在某些情况下这很有用。