By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), February 14, 2013 4:44 pm
Room: Moderated Discussions
rwessel (robertwessel.delete@this.yahoo.com) on February 14, 2013 4:14 pm wrote:
>
> As I mentioned elsewhere in this thread, compare-and-branch is an excellent choice, but I'd really
> also want something to do a compare without a branch. You want to be able to combine some simple
> tests without a branch, and to do some limited predication. Not always, but there are definitely
> times to want those. Compare-and-set-GPR seems like a better choice there than actual CCs.
There's nothing wrong with having a flags register. It's in many ways much superior to the alternatives.
In contrast, multiple CC registers are just stupid. It just makes things actively worse for renaming, it's horrible for instruction encoding, and the win is basically zero. The argument for multiple CC's is just stupid too, and seems to be about idiotic in-order machines. Let them die already, and accept the fact that it's much better to have multiple CC's through renaming.
And compare-and-branch may be "clean", but again, it's just a instruction encoding nightmare, since you *do* need to also be able to compute the value or do things like conditional moves, for value setting etc etc.
So a (single) flags register is just fine. It works. The flags make it easy to do different things depending on the conditional - setting values, conditional moves, branches, whatever. They have no serious downsides, and having a separate register space is more flexible and not really complicated.
There is not really any sane argument against having a flags register.
Now, you can certainly do flags registers wrong. The x86 model where some instructions write some bits but not all is just bad, and forces the microarchitecture to either rename it basically bit-by-bit, or not rename it at all. That's just wrong, and a mistake. But that's just a particular detail of an odd implementation of having a condition flags register, it shouldn't be seen as "flags are evil".
And the x86 one is still better than the abortion that is the PowerPC crap. The fact that anybody brought the idiotic powerpc model as an example of how to do things "right" is just sad. What a crock.
And putting the condition codes in GPRs (alpha) may look really clean and allows some nice combined conditionals, but the upside just isn't there. It doesn't really generate better code: you win some, you lose some.
Linus
>
> As I mentioned elsewhere in this thread, compare-and-branch is an excellent choice, but I'd really
> also want something to do a compare without a branch. You want to be able to combine some simple
> tests without a branch, and to do some limited predication. Not always, but there are definitely
> times to want those. Compare-and-set-GPR seems like a better choice there than actual CCs.
There's nothing wrong with having a flags register. It's in many ways much superior to the alternatives.
In contrast, multiple CC registers are just stupid. It just makes things actively worse for renaming, it's horrible for instruction encoding, and the win is basically zero. The argument for multiple CC's is just stupid too, and seems to be about idiotic in-order machines. Let them die already, and accept the fact that it's much better to have multiple CC's through renaming.
And compare-and-branch may be "clean", but again, it's just a instruction encoding nightmare, since you *do* need to also be able to compute the value or do things like conditional moves, for value setting etc etc.
So a (single) flags register is just fine. It works. The flags make it easy to do different things depending on the conditional - setting values, conditional moves, branches, whatever. They have no serious downsides, and having a separate register space is more flexible and not really complicated.
There is not really any sane argument against having a flags register.
Now, you can certainly do flags registers wrong. The x86 model where some instructions write some bits but not all is just bad, and forces the microarchitecture to either rename it basically bit-by-bit, or not rename it at all. That's just wrong, and a mistake. But that's just a particular detail of an odd implementation of having a condition flags register, it shouldn't be seen as "flags are evil".
And the x86 one is still better than the abortion that is the PowerPC crap. The fact that anybody brought the idiotic powerpc model as an example of how to do things "right" is just sad. What a crock.
And putting the condition codes in GPRs (alpha) may look really clean and allows some nice combined conditionals, but the upside just isn't there. It doesn't really generate better code: you win some, you lose some.
Linus
