By: EduardoS (no.delete@this.spam.com), February 25, 2013 5:55 pm
Room: Moderated Discussions
Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 25, 2013 5:24 pm wrote:
> Well then you'll be surprised to hear that there are more adds/subs
> followed by a beq/bne than all logical operations combined...
For SUBS I agree, but not for ADDS.
> You're talking about the cumulative exception flags, right?
Not exactly.
> Those are completely separate
> and not directly usable by branches like a normal condition code. ARM has around 7
> such flags. They are pretty much completely useless so remain unused. With FP you only
> need to check the final result to check whether it is meaningless or not.
And check after each operation when you want to know where things gone wrong.
> The point is that the overflow check will be different in different languages.
Yes.
> If you write it explicitly
> in C then it doesn't matter if the hardware doesn't support a branch on overflow operation - as it
> won't be used anyway (yes some cases could be peepholed, but typical programmers write such checks
> in the most horrible and inefficient way that that is unlikely in general unfortunately).
When overflow check is important C will hardly be the language of choice, C have too many others sources of silent corruption wich are much harder to workaround.
My point is, sometimes it matters and, when it matters it is better the hardware provide it.
> If going all-out on flags, what about a flag for all-ones, top 16/24-bits zero (or same-sign
> as bit 15/23), even/odd, parity etc. Half/quarter carry? Just where do you stop?
The four most important: Zero, Carry, Sign and Overflow
The Carry and Overflow are special in the sense that they do not appear directly in the result of an logic or arithmetic instruction.
Parity sometimes is nice (I have one case using it, as a parity, not as a help flag for floating point) but a "get parity" instruction is enough.
> Well then you'll be surprised to hear that there are more adds/subs
> followed by a beq/bne than all logical operations combined...
For SUBS I agree, but not for ADDS.
> You're talking about the cumulative exception flags, right?
Not exactly.
> Those are completely separate
> and not directly usable by branches like a normal condition code. ARM has around 7
> such flags. They are pretty much completely useless so remain unused. With FP you only
> need to check the final result to check whether it is meaningless or not.
And check after each operation when you want to know where things gone wrong.
> The point is that the overflow check will be different in different languages.
Yes.
> If you write it explicitly
> in C then it doesn't matter if the hardware doesn't support a branch on overflow operation - as it
> won't be used anyway (yes some cases could be peepholed, but typical programmers write such checks
> in the most horrible and inefficient way that that is unlikely in general unfortunately).
When overflow check is important C will hardly be the language of choice, C have too many others sources of silent corruption wich are much harder to workaround.
My point is, sometimes it matters and, when it matters it is better the hardware provide it.
> If going all-out on flags, what about a flag for all-ones, top 16/24-bits zero (or same-sign
> as bit 15/23), even/odd, parity etc. Half/quarter carry? Just where do you stop?
The four most important: Zero, Carry, Sign and Overflow
The Carry and Overflow are special in the sense that they do not appear directly in the result of an logic or arithmetic instruction.
Parity sometimes is nice (I have one case using it, as a parity, not as a help flag for floating point) but a "get parity" instruction is enough.