为什么INC和DEC指令*不*影响进位标志(CF)? [英] Why do the INC and DEC instructions *not* affect the Carry Flag (CF)?

问题描述

为什么x86指令INC(递增)和DEC(递减)不影响FLAGSREGISTER中的CF(进位标志)?

Why do the x86 instruction INC (increment) and DEC (decrement) not affect the CF (carry flag) in FLAGSREGISTER?

推荐答案

要了解为什么您可能需要记住当前具有32位和64位值的"x86" CPU，为什么要使用有限的8位计算机，所以要追溯到过去到Intel8008.(我在1973年在这个世界上编码，我仍然记得(嗯)！).

To understand why you probably need to remember the current "x86" CPUs with 32 and 64 bit values started life as much more limited 8-bit machines, going back to the Intel 8008. (I coded in this world back in 1973, I still remember (ugh) it!).

在那个世界上，登记簿既珍贵又小.您出于各种目的需要INC/DEC，最常见的是循环控制.许多循环涉及执行多精度算术"(例如16位或更多！)，通过将INC/DEC设置为零标志(Z)，可以很好地使用它们来控制循环.通过坚持要求循环控制指令不更改进位"标志(CF)，可在循环迭代中保留进位，并且无需编写大量代码即可记住进位状态，就可以实现多精度操作.

In that world, registers were precious and small. You need INC/DEC for various purposes, the most common being loop control. Many loops involved doing "multi-precision arithmetic" (e.g, 16 bits or more!) By having INC/DEC set the Zero flag (Z), you could use them to control loops pretty nicely; by insisting the loop control instructions not change the Carry flag (CF), the carry is preserved across loop iterations and you can implement multiprecision operations without writing tons of code to remember the carry state.

一旦您习惯了丑陋的指令集，它的效果就很好.

This worked pretty well, once you got used to the ugly instruction set.

在更现代的具有较大字长的计算机上，您不需要太多，因此INC和DEC在语义上可以等同于ADD ...，1等.事实上，这就是我当我需要携带套时使用:-}

On more modern machines with larger word sizes, you don't need this is much, so INC and DEC could be semantically equivalent to ADD ...,1 etc. That in fact is what I use when I need the carry set :-}

大多数情况下，我现在不使用INC和DEC，因为它们会进行部分条件代码更新，这会导致管道中出现有趣的停顿，而ADD/SUB不会.因此，在没有关系的地方(大多数地方)，我使用ADD/SUB来避免停顿.我仅在将代码保持在很小的范围内时才使用INC/DEC，例如，适合一条或两条指令的大小足以引起影响的高速缓存行.这可能是毫无意义的nano [literal！]优化，但是我的编码习惯相当老套.

Mostly, I stay away from INC and DEC now, because they do partial condition code updates, and this can cause funny stalls in the pipeline, and ADD/SUB don't. So where it doesn't matter (most places), I use ADD/SUB to avoid the stalls. I use INC/DEC only when keeping the code small matters, e.g., fitting in a cache line where the size of one or two instructions makes enough difference to matter. This is probably pointless nano[literally!]-optimization, but I'm pretty old-school in my coding habits.

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

My explanation tells us why INC/DEC set the Zero flag (Z). I don't have a particularly compelling explanation for why INC/DEC set the sign (and the Parity flag).

编辑2016年4月:似乎在现代x86上更好地解决了停顿问题.请参见 INC指令与ADD 1:有关系吗?

EDIT April 2016: It seems that the stall problem is handled better on modern x86s. See INC instruction vs ADD 1: Does it matter?

这篇关于为什么INC和DEC指令*不*影响进位标志(CF)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！