patternModerate
why do CPU architectures use a flags register (advantages?)
Viewed 0 times
whyadvantagesarchitecturesregisterflagscpuuse
Problem
Some CPUs have a flags register (ARM,x86,...), others don't (MIPS,...). What's the advantage of having a CMP instruction to update the flags register followed by a branch instruction instead of using a zero register and conditional branches to check for sign, overflow etc?
Solution
In modern micro-architectures with register renaming the implementation cost for flags or not flags is pretty similar. The main difference I can think of is that some flags indicate the characteristics of a value (Is the value negative? Is the value zero? Does the value have even or odd parity?), while some represent an event that occurred during a previous operation (did the add instruction have a carry out or an overflow?) This led to a less-than-ideal situation on the MIPS when you wanted to simulate 64-bit addition on the 32-bit architecture (or 128-bit addition on the 64-bit architecture.) On most architectures with a carry flag there is a special
On the flip side, testing an N-bit register for zero or not-zero is actually surprisingly expensive. To test an N-bit register for zero you need to perform an N-bit NOR operation, which requires $O(\log N)$ levels of logic to calculate. On architectures with flags registers the extra logic for the zero/not-zero calculation at the end of the ALU stage can cause the clock to run slower (or force the ALU to have two cycle operations.) For this reason, I think, some architectures, like SPARC had two versions of each arithmetic operation, one that set flags and one that didn't.
But MIPS doesn't save anything here. They just moved the problem somewhere else. On MIPS there is a
The DEC Alpha architecture tried to split the difference by using a trick. DEC Alpha had no flags registers, but also didn't have a
add-with-carry instruction, that includes the carry flag from the previous add instruction. This makes simulating multi-precision arithmetic relatively inexpensive on many architectures with flags registers.On the flip side, testing an N-bit register for zero or not-zero is actually surprisingly expensive. To test an N-bit register for zero you need to perform an N-bit NOR operation, which requires $O(\log N)$ levels of logic to calculate. On architectures with flags registers the extra logic for the zero/not-zero calculation at the end of the ALU stage can cause the clock to run slower (or force the ALU to have two cycle operations.) For this reason, I think, some architectures, like SPARC had two versions of each arithmetic operation, one that set flags and one that didn't.
But MIPS doesn't save anything here. They just moved the problem somewhere else. On MIPS there is a
branch-on-equal instruction. This means that the branch instruction must actually have an ALU stage (including something like a bitwise xor operation followed by a nor to reduce down to the single equal/not-equal bit) before determining which way the branch goes.The DEC Alpha architecture tried to split the difference by using a trick. DEC Alpha had no flags registers, but also didn't have a
branch-on-equal instruction. Instead the branch instructions all look at the state of a single general purpose register. There is branch-on-zero, branch-on-not-zero, branch-on-less-than-zero, etc. The trick is that you can give every general purpose register an extra 65th bit that tells you whether the other 64 bits are all zero or not. This makes it more like having a flags register: all the branch instructions look at a single bit (that is already calculated) to make their decision, but now you are back to figuring out how to calculate that extra zero indicator bit during a normal ALU cycle. (And you still can't do multi-precision arithmetic just by looking at the carry flag from the previous operation.)Context
StackExchange Computer Science Q#30477, answer score: 11
Revisions (0)
No revisions yet.