Why do the INC and DEC instructions *not* affect the Carry Flag (CF)?

Question

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

Answer 1

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!).

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.

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 :-}

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.

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).

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

Answer 2

The question of why sign when you have zero flag set by inc/dec is best addressed with question: would you rather do without option a ?

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

As Ira Baxter already clarified, Carry flag is used in a lot of algorithms -- not only multiprecision arithmetic, but also for say bitmap processing in monochrome/cga/EGA era: This shifts 80 pixel wide row one pixel right...

        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 // 

But then: why parity?

I believe the answer is why not. This instruction set is from the late 70's, when transistors were scarce. Denying the calculation of parity flag for some particular instruction would have not made any sense, but just added to the complexity of the CPU.