Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 19, 2013 6:41 pm wrote:
> Btw, I'm sure the numbers change from compiler to compiler, and almost certainly by architecture. For example,
> on x86, you may notice that some programs test the "parity" flag, which looks odd. It certainly threw me.
>
> It turns out that they are testing for the floating point "unordered" bit, which uses the otherwise
> almost entirely unused parity bit (because unlike integer comparisons, for floating point you
> can show the unordered state in addition to the normal equality and inequality cases).
>
> So no, you really don't want just a single bit of result for comparisons. Not for integer, and certainly
> not for floating point.

There is no difference between integer or floating point. One condition bit is enough to hold the result of any comparison. That's undeniable.

> The "unordered" thing is just an example of that, and if you have instructions
> that conditionally write the flags (like "add." or whatever), you definitely don't want to spend more
> than a single opcode on that, even if the user may well then care about negative/zero/overflow.

For ALU instructions you only need equality, as that gives 96% of all uses. And ALU+branch is rare to start with.

> So the sane thing is to do the traditional flags model. It works. I'm surprised you even argue
> about it, since it's what your beloved ARM does too.

Guess who added compare&branch to the ARM architecture?

> And no, the bits aren't random and no,
> they don't change between architectures (although the names and locations differ).

Wrong. The semantics of condition bits varies significantly between architectures. Consider the complexity of emulating x86 flags on ARM or visa versa.

Wilco