By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), February 26, 2013 11:13 am
Room: Moderated Discussions
Matthew D (mattd.delete@this.example.com) on February 26, 2013 12:07 am wrote:
> Although everyone agrees what the carry bit should do after an add, there are two conventions
> for the value of the carry bit after a subtract (or compare). They're both in common use.
Oh, absolutely. But that still falls under "naming and position" details. It doesn't change the fact that everybody really wants the same things, they just sometimes call it something else and put it in odd locations or have random details due to historical artifacts.
The four basic flags really are about math and fundamental operations. The fact that there are then various implementation-specific details about exactly how they are encoded is a separate thing, and no different from any other "instruction sets encode things differently" issue.
Carry and overflow are the ones that tend to be odder than most, since they encode stuff not directly visible in the result, so semantics aren't quite as fixed (your borrow example is good). Also, they both tend to be involved in multiple dependent operations.
Carry is used not just for individual operations, but often for multi-precision arithmetic (so there are architectures that duplicate it in multiple locations for different uses) and overflow is often something that you end up checking much later (and there are architectures that do at least two different overflow bits: a "last operation" overflow, and a "sticky" overflow which just accumulates overflow bits).
So yes, I don't dispute that the exact bit pattern details etc change. But I do claim that the four flags are fundamental, and not at all random and implementation-defined in any conceptual sense. The same way everybody wants to have an "add" instruction, everybody pretty much wants to have the four status bits. They just sometimes get encoded really oddly (where "really oddly" can include "don't ever have an instruction that sets them all, but have lots of instructions to set each case separately", which I argue is stupid and only complicates things).
Linus
> Although everyone agrees what the carry bit should do after an add, there are two conventions
> for the value of the carry bit after a subtract (or compare). They're both in common use.
Oh, absolutely. But that still falls under "naming and position" details. It doesn't change the fact that everybody really wants the same things, they just sometimes call it something else and put it in odd locations or have random details due to historical artifacts.
The four basic flags really are about math and fundamental operations. The fact that there are then various implementation-specific details about exactly how they are encoded is a separate thing, and no different from any other "instruction sets encode things differently" issue.
Carry and overflow are the ones that tend to be odder than most, since they encode stuff not directly visible in the result, so semantics aren't quite as fixed (your borrow example is good). Also, they both tend to be involved in multiple dependent operations.
Carry is used not just for individual operations, but often for multi-precision arithmetic (so there are architectures that duplicate it in multiple locations for different uses) and overflow is often something that you end up checking much later (and there are architectures that do at least two different overflow bits: a "last operation" overflow, and a "sticky" overflow which just accumulates overflow bits).
So yes, I don't dispute that the exact bit pattern details etc change. But I do claim that the four flags are fundamental, and not at all random and implementation-defined in any conceptual sense. The same way everybody wants to have an "add" instruction, everybody pretty much wants to have the four status bits. They just sometimes get encoded really oddly (where "really oddly" can include "don't ever have an instruction that sets them all, but have lots of instructions to set each case separately", which I argue is stupid and only complicates things).
Linus
