By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), February 25, 2013 6:22 pm
Room: Moderated Discussions
Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 25, 2013 6:05 am wrote:
>
> > And no, the bits aren't random and no,
> > they don't change between architectures (although the names and locations differ).
>
> Wrong. The semantics of condition bits varies significantly between architectures.
> Consider the complexity of emulating x86 flags on ARM or visa versa.
Bah. None of the semantics differs in any real sense. Yes, the details matter (some instructions set some bits, not all bits), but the four core bits are exactly the same for the very simple reason that it's all math, and it's totally independent of any instruction set.
Yes, emulating x86 flags is bothersome, but that's just because the exact locations and other silly details. Auxiliary carry, parity etc are historical artifacts. Same goes for "inc/dec do not touch carry" (which is, I think, due to trying to preserve carry around loop iterations for multiprecision arithmetic) and the rather specific semantics for carry and shifts (which do make sense from an original iterative bit-at-a-time implementation standpoint but not from a barrel shifter one).
Similarly, the fact that x86 FP puts the unordered bit in PF (I think ARM puts it in VF) is just a random implementation choice.
And none of that actually affects the "four bits of flags make universal sense". As I said, the exact locations and names differ, and yes, that makes emulation not be a 1:1 translation thing, but that is *totally* irrelevant to whether the flags are universal or not.
The bit pattern of the encoding of an "add" instruction are different in different instruction sets, but that doesn't change the fact that "add" is fundamental. Same goes for the zero, carry, overflow, sign bits.
And having four bits means that you don't need many different versions of "add with carry" vs "subtract with sign flag" crap.
Plus there is absolutely no downside. The difference between one and four bits is totally irrelevant, except for the "four bits has more information" part which makes it more powerful. Writing one bit vs writing four bits is a non-issue. As mentioned, four bits of flags allow for a more powerful and straightforward instruction model, where you don't need to waste pointless bits in the actual encoding.
Btw, if you want to create a compare-and-jump instruction, you could do worse (a *lot* worse, in fact) than the intel instruction fusing approach.
Linus
>
> > And no, the bits aren't random and no,
> > they don't change between architectures (although the names and locations differ).
>
> Wrong. The semantics of condition bits varies significantly between architectures.
> Consider the complexity of emulating x86 flags on ARM or visa versa.
Bah. None of the semantics differs in any real sense. Yes, the details matter (some instructions set some bits, not all bits), but the four core bits are exactly the same for the very simple reason that it's all math, and it's totally independent of any instruction set.
Yes, emulating x86 flags is bothersome, but that's just because the exact locations and other silly details. Auxiliary carry, parity etc are historical artifacts. Same goes for "inc/dec do not touch carry" (which is, I think, due to trying to preserve carry around loop iterations for multiprecision arithmetic) and the rather specific semantics for carry and shifts (which do make sense from an original iterative bit-at-a-time implementation standpoint but not from a barrel shifter one).
Similarly, the fact that x86 FP puts the unordered bit in PF (I think ARM puts it in VF) is just a random implementation choice.
And none of that actually affects the "four bits of flags make universal sense". As I said, the exact locations and names differ, and yes, that makes emulation not be a 1:1 translation thing, but that is *totally* irrelevant to whether the flags are universal or not.
The bit pattern of the encoding of an "add" instruction are different in different instruction sets, but that doesn't change the fact that "add" is fundamental. Same goes for the zero, carry, overflow, sign bits.
And having four bits means that you don't need many different versions of "add with carry" vs "subtract with sign flag" crap.
Plus there is absolutely no downside. The difference between one and four bits is totally irrelevant, except for the "four bits has more information" part which makes it more powerful. Writing one bit vs writing four bits is a non-issue. As mentioned, four bits of flags allow for a more powerful and straightforward instruction model, where you don't need to waste pointless bits in the actual encoding.
Btw, if you want to create a compare-and-jump instruction, you could do worse (a *lot* worse, in fact) than the intel instruction fusing approach.
Linus
