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

查看:25
本文介绍了为什么 INC 和 DEC 指令*不*影响进位标志 (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 位计算机一样,回溯到 Intel 8008.(我 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.

在更现代的具有更大字号的机器上,你不需要太多,所以 INCDEC 可以在语义上等同于 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 :-}

大多数情况下,我现在远离 INCDEC,因为它们会执行部分条件代码更新,这会导致管道中出现有趣的停顿,并且 ADD/SUB 不要.所以在无关紧要的地方(大多数地方),我使用 ADD/SUB 来避免停顿.我使用 INC/DEC 只在保持代码小问题时使用,例如,适合一两条指令的大小足以影响的缓存行.这可能是毫无意义的纳米[字面意思!]优化,但我的编码习惯非常老派.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆