What the FLAGS Register Tracks
The x86 FLAGS register (EFLAGS on 32-bit, RFLAGS on 64-bit) is a special-purpose register where individual bits, not the whole value, carry meaning. Most arithmetic and logic instructions update a subset of these bits automatically as a side effect: ZF (zero flag) is set when a result is zero, SF (sign flag) mirrors the most significant bit of the result, CF (carry flag) records an unsigned carry or borrow out of the most significant bit, and OF (overflow flag) records signed overflow. These flags are never read directly as a number in normal code; instead, conditional jump and conditional move instructions test specific flags or combinations of them.
Cricket analogy: The FLAGS register is like a scoreboard's set of individual indicator lights — one for 'new batsman', one for 'powerplay active', one for 'DRS pending' — each bit meaningful on its own rather than the panel being read as one big number.
Carry Flag vs. Overflow Flag
CF and OF are frequently confused but answer different questions. CF signals that an unsigned addition or subtraction produced a result requiring a carry out of (or borrow into) the highest bit — it is meaningful when treating the operands as unsigned numbers. OF signals that a signed addition or subtraction produced a result outside the representable signed range for that operand size — for example, adding two large positive 32-bit numbers that overflow into a negative-looking result sets OF but might leave CF clear, and vice versa. A single ADD instruction updates both flags simultaneously, but only one is relevant depending on whether you're treating the data as signed or unsigned.
Cricket analogy: CF is like a run-rate calculator flagging when the required rate becomes mathematically impossible with balls remaining (an unsigned resource limit), while OF is like a net-run-rate figure crossing into implausible territory when the maths of the format breaks — two different overflow concepts from the same scoreline.
section .text
global _start
_start:
mov al, 0x7F ; 127, max positive signed byte
add al, 1 ; result: 0x80 = -128 signed, but 128 unsigned
jo signed_overflow ; OF is set: signed overflow occurred
jnc no_unsigned_carry ; CF is clear: no unsigned carry occurred
signed_overflow:
mov ebx, 1
jmp report
no_unsigned_carry:
mov ebx, 2
report:
mov eax, 1 ; sys_exit
int 0x80Flags in Conditional Moves and Adjustments
Flags aren't only consumed by jumps. CMOVcc (conditional move) instructions copy a value only if a flag condition holds, letting compilers avoid branch misprediction penalties for simple ternary expressions. SETcc instructions write a 0 or 1 byte into a register based on a flag condition, useful for converting a comparison directly into a boolean value without branching at all. The AF (auxiliary carry flag) exists specifically to support decimal adjustment instructions like DAA, tracking carries out of the low nibble for binary-coded decimal arithmetic — a legacy feature rarely used in modern code but still updated by every ADD and SUB.
Cricket analogy: SETcc is like a scoreboard operator instantly flipping a binary 'boundary/no boundary' indicator the moment the ball crosses the rope, without waiting for a formal review process — a direct flag-to-value conversion, just like SETcc turning a comparison straight into 0 or 1.
Because branch misprediction can cost 15-20 cycles on modern out-of-order CPUs, compilers frequently prefer CMOVcc or SETcc over an equivalent Jcc sequence for short, data-independent conditionals — this is a major reason optimized assembly sometimes looks less 'branchy' than a direct translation of the source code would suggest.
Not every flag is preserved across every instruction. Bitwise logic instructions like AND, OR, and XOR always clear CF and OF to 0 regardless of the operands, while updating ZF and SF normally — assuming CF still reflects an earlier arithmetic carry after a logic instruction is a common source of incorrect conditional branches.
- The FLAGS register packs multiple independently meaningful status bits, not a single numeric value.
- ZF, SF, CF, and OF are the four flags most commonly tested by conditional jumps.
- CF tracks unsigned carry/borrow; OF tracks signed overflow — a single instruction can set one without the other.
- SETcc converts a flag condition directly into a 0 or 1 byte without branching.
- CMOVcc conditionally copies a value based on flags, avoiding branch misprediction penalties.
- AF supports legacy binary-coded decimal instructions like DAA and is rarely used directly in modern code.
- Bitwise instructions like AND/OR/XOR always clear CF and OF, which can silently invalidate assumptions carried from earlier arithmetic.
Practice what you learned
1. Which flag specifically indicates signed arithmetic overflow?
2. What happens to CF and OF after a bitwise AND instruction?
3. What does the SETcc instruction do?
4. Why might a compiler prefer CMOVcc over an equivalent Jcc-based branch?
5. Can a single ADD instruction set OF without setting CF, or vice versa?
Was this page helpful?
You May Also Like
Conditional Jumps
Learn how x86 assembly implements if/else logic using flag-testing conditional jump instructions like JE, JNE, JG, and JL.
Loops in Assembly
Discover how high-level for and while loops are built from conditional jumps, counters, and the dedicated LOOP instruction in x86 assembly.
Procedures and Calling Conventions
Learn how assembly functions are called, how arguments and return values are passed, and how the stack frame is built and torn down.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics