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

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. And no, the bits aren't random and no, they don't change between architectures (although the names and locations differ).

Linus