By: Gabriele Svelto (gabriele.svelto.delete@this.gmail.com), February 15, 2013 2:28 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 14, 2013 4:44 pm wrote:
> 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.
Due to the very compact instruction encoding SuperH processors use a system which is probably the "cleanest" I've seen: they have a single-bit flag register (T register) which is implicitly set by comparison operations and read by conditional branch instructions. Additionally you have an instruction to move its contents to a GPR (which is as cheap as regular register moves in the actual implementations). Only some fixed-point instruction which are not comparisons can set it and those are the ones typically used for multi-precision arithmetic (like add-with-carry, add-with-overflow, etc...).
Since it's been used only in relatively low-performance cores I don't know how it would scale to a wide, deeply pipelined OoOE engine but I don't see any major drawbacks. I think that having basically only one register and a handful of instructions that can peek and poke at it should make it easy to aggressively rename it.
> 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.
Due to the very compact instruction encoding SuperH processors use a system which is probably the "cleanest" I've seen: they have a single-bit flag register (T register) which is implicitly set by comparison operations and read by conditional branch instructions. Additionally you have an instruction to move its contents to a GPR (which is as cheap as regular register moves in the actual implementations). Only some fixed-point instruction which are not comparisons can set it and those are the ones typically used for multi-precision arithmetic (like add-with-carry, add-with-overflow, etc...).
Since it's been used only in relatively low-performance cores I don't know how it would scale to a wide, deeply pipelined OoOE engine but I don't see any major drawbacks. I think that having basically only one register and a handful of instructions that can peek and poke at it should make it easy to aggressively rename it.