By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), February 15, 2013 6:34 pm
Room: Moderated Discussions
Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 15, 2013 5:46 pm wrote:
>
> That's a good tradeoff, but you need 3 extra bits on compares of course
It's worse than that. You'll want to do subtract-and-test, bitops, yadda yadda. Compare really isn't even close to complete. Otherwise you'll just end up playing games with other arithmetic-logical ops to then be able to compare the result. Which is *not* an improvement, no matter how some people would want to twist it,
The whole "decrement loop counter and test" is common enough to merit special logic (sometimes to the point of having special loop registers, like powerpc).
The thing is, the traditional "just have a flags register" really is hard to beat. People have tried, and people have inevitably failed. Not a single architecture has ever done better than that. I don't understand why people try so hard.
And no, reducing the flag register to a single bit isn't a win either.
Seriously, why would it be? It just shifts the decoding bits around by a tiny amount, and not in a good way. The only reason to think it's an advantage is if you have an overly restrictive decoder, so that for some particular instruction encoding the "shift bits around" can be seen as a good thing.
But while it can be a win for some particular encoding model, it's a *bad* thing in general. It just makes it much harder to do all the things people use flags for. Yes, that includes carry, but it also includes "test against zero and negative at the same time" etc etc.
People really do that - small case-statements turn into "test against an exact match of one value, and larger-than and smaller-than AT THE SAME TIME". And it's totally natural and correct to do with a flags register, and anybody who disputes that is just in denial.
So "one bit of flags" is just a sign of working around particular bitpattern encoding issues rather than "it's actually a good thing". It's a *bad* thing. You want at least three bits for the conditionals probably four or five bits of flags total (depending a bit on whether you care to encode overflow separately etc).
There's a reason a lot of architectures used flags and made it possible to set them in most arithmetic ops. It's flexible and powerful, and you really do want them for most arithmetic ops. And doing it unconditionally for pretty much everything (like x86 does) is an actual encoding space advantage, even if some people will have a hard time admitting that, and will want to have the extra "enable" bit for it.
Linus
>
> That's a good tradeoff, but you need 3 extra bits on compares of course
It's worse than that. You'll want to do subtract-and-test, bitops, yadda yadda. Compare really isn't even close to complete. Otherwise you'll just end up playing games with other arithmetic-logical ops to then be able to compare the result. Which is *not* an improvement, no matter how some people would want to twist it,
The whole "decrement loop counter and test" is common enough to merit special logic (sometimes to the point of having special loop registers, like powerpc).
The thing is, the traditional "just have a flags register" really is hard to beat. People have tried, and people have inevitably failed. Not a single architecture has ever done better than that. I don't understand why people try so hard.
And no, reducing the flag register to a single bit isn't a win either.
Seriously, why would it be? It just shifts the decoding bits around by a tiny amount, and not in a good way. The only reason to think it's an advantage is if you have an overly restrictive decoder, so that for some particular instruction encoding the "shift bits around" can be seen as a good thing.
But while it can be a win for some particular encoding model, it's a *bad* thing in general. It just makes it much harder to do all the things people use flags for. Yes, that includes carry, but it also includes "test against zero and negative at the same time" etc etc.
People really do that - small case-statements turn into "test against an exact match of one value, and larger-than and smaller-than AT THE SAME TIME". And it's totally natural and correct to do with a flags register, and anybody who disputes that is just in denial.
So "one bit of flags" is just a sign of working around particular bitpattern encoding issues rather than "it's actually a good thing". It's a *bad* thing. You want at least three bits for the conditionals probably four or five bits of flags total (depending a bit on whether you care to encode overflow separately etc).
There's a reason a lot of architectures used flags and made it possible to set them in most arithmetic ops. It's flexible and powerful, and you really do want them for most arithmetic ops. And doing it unconditionally for pretty much everything (like x86 does) is an actual encoding space advantage, even if some people will have a hard time admitting that, and will want to have the extra "enable" bit for it.
Linus