By: Michael S (already5chosen.delete@this.yahoo.com), February 28, 2013 1:39 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 27, 2013 5:41 pm wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on February 27, 2013 4:24 pm wrote:
> >
> > Now, do we really need 4 flag bits in order to implement 12 (or even all 14) fundamental
> > conditions? No, we don't
>
> Oh, I'm sure you can encode it some odd way, since as you say, there are only 14 normal conditions you
> want to check, and half of them are the reverse ones. So pretty much by definition you could do some
> kind of "perfect hash" to map the actual conditions you get out of an ALU into just three bits.
>
> But why would you? Especially since the four normal flag bits are literally what you get our of a two's-complement
> ALU with the simplest possible rules. So the re-encoding is still going to *compute* the four bits, it is then
> just going to hash them down to the particular combinations you wanted. It's not like the bits themselves disappeared,
> you just encoded them more densely by knowing which combinations people will test.
>
> So I do claim that the 4 bits are pretty fundamental, the same way two's-complement is fundamental.
It depends on implementation of ALU. Only SF and CF are obviously here. OF may take additional logic in some implementations or come for almost free in others. As to ZF, it's probably requires specialized logic in most implementations.
Anyway, both calculations of ZSCO flags and their alternative encoding methodes are very small part of the total ALU and likely not on a critical timing path. Except, possibly, of forwarding of CF for ADC/SBB.
> Sure, you
> can encode numbers in base three too if you want to, but that doesn't make binary numbers any less fundamental
Not the same and not even similar to discussion at hand. Base three makes sense only when you storage elements can naturally distinguish between 3 states. When implemented with binary storage elements, it radically less dense than base two.
> - even if the "fundamental" nature of them ends up being at least partly about sanity of implementation.
>
> Linus
IMHO, 3-bit encoding allows perfectly sane implementation. For very simple designs with predictor-less jump resolution there could be even small implementation advantage in the fact that take/not-take decision depends on fewer bits.
> Michael S (already5chosen.delete@this.yahoo.com) on February 27, 2013 4:24 pm wrote:
> >
> > Now, do we really need 4 flag bits in order to implement 12 (or even all 14) fundamental
> > conditions? No, we don't
>
> Oh, I'm sure you can encode it some odd way, since as you say, there are only 14 normal conditions you
> want to check, and half of them are the reverse ones. So pretty much by definition you could do some
> kind of "perfect hash" to map the actual conditions you get out of an ALU into just three bits.
>
> But why would you? Especially since the four normal flag bits are literally what you get our of a two's-complement
> ALU with the simplest possible rules. So the re-encoding is still going to *compute* the four bits, it is then
> just going to hash them down to the particular combinations you wanted. It's not like the bits themselves disappeared,
> you just encoded them more densely by knowing which combinations people will test.
>
> So I do claim that the 4 bits are pretty fundamental, the same way two's-complement is fundamental.
It depends on implementation of ALU. Only SF and CF are obviously here. OF may take additional logic in some implementations or come for almost free in others. As to ZF, it's probably requires specialized logic in most implementations.
Anyway, both calculations of ZSCO flags and their alternative encoding methodes are very small part of the total ALU and likely not on a critical timing path. Except, possibly, of forwarding of CF for ADC/SBB.
> Sure, you
> can encode numbers in base three too if you want to, but that doesn't make binary numbers any less fundamental
Not the same and not even similar to discussion at hand. Base three makes sense only when you storage elements can naturally distinguish between 3 states. When implemented with binary storage elements, it radically less dense than base two.
> - even if the "fundamental" nature of them ends up being at least partly about sanity of implementation.
>
> Linus
IMHO, 3-bit encoding allows perfectly sane implementation. For very simple designs with predictor-less jump resolution there could be even small implementation advantage in the fact that take/not-take decision depends on fewer bits.
