By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), February 17, 2013 6:07 pm
Room: Moderated Discussions
Jouni Osmala (josmala.delete@this.cc.hut.fi) on February 17, 2013 1:10 pm wrote:
[snip]
> No since that && in if statement is short circuit statement.
In many cases condition evaluation does not have side effects, so it is safe to ignore short circuit semantics.
> if((a!=null)&&(*a==b))
> With any compiler trying to do that with 2 CC registers, would
> remove an effect of null check that language definition states would work.
If null pointer based loads returned zero rather than a possible memory protection exception, then the side effect problem would be removed (and some systems have provided that guarantee).
[snip]
> And for that to work the way you want you would need logical operations to flags registers.
> That means extra read ports there and special unit to handle it.
The extra read ports would probably not be that big a deal since condition values are typically not read that frequently.
> I like the alpha way for this, as compares write normal registers to 1 or 0 depending on condition.
> Assuming a,b,c,d are already in registers. And maybe needed later.
I think using -1 (all bits set) as true is better. (Most SIMD comparison operations do this.) The main advantages of returning 1 for true seem to be compatibility with C and (perhaps?) the ability to use shifted add to conditionally increment a point (shifted subtract is not commonly provided). The somewhat common use of select value or zero can also be replaced with a simple AND.
[snip]
> The best thing about alpha approach is that its reusing the normal register renaming hardware to
> conditions. No matter what many software people tell you, the key of optimizing is not doing more
> in hardware, the key of optimization is getting rid of unnecessary work. And that is what alpha version
> does. It removes the need for reservation stations to track condition code dependencies.
It might be noted that reading a 64-bit register to get less than three bits of information (Alpha supported test for zero, sign bit set, and least significant bit set in branches) would also be more work. The renaming of a single CC is not that bad, and the dependency tracking does not need to be exceptionally more complex (adding one bit to the CAM of one operand might be a straightforward way of dealing with this; better solutions doubtless exist).
The Alpha design is cleaner in some respects, but it is not clear that it always reduces unnecessary work. In addition, unnecessary work (e.g., speculation which might be wrong) may provide improved performance. (I know this is obvious, but stating such might be useful to some less informed lurker.)
[snip]
> No since that && in if statement is short circuit statement.
In many cases condition evaluation does not have side effects, so it is safe to ignore short circuit semantics.
> if((a!=null)&&(*a==b))
> With any compiler trying to do that with 2 CC registers, would
> remove an effect of null check that language definition states would work.
If null pointer based loads returned zero rather than a possible memory protection exception, then the side effect problem would be removed (and some systems have provided that guarantee).
[snip]
> And for that to work the way you want you would need logical operations to flags registers.
> That means extra read ports there and special unit to handle it.
The extra read ports would probably not be that big a deal since condition values are typically not read that frequently.
> I like the alpha way for this, as compares write normal registers to 1 or 0 depending on condition.
> Assuming a,b,c,d are already in registers. And maybe needed later.
I think using -1 (all bits set) as true is better. (Most SIMD comparison operations do this.) The main advantages of returning 1 for true seem to be compatibility with C and (perhaps?) the ability to use shifted add to conditionally increment a point (shifted subtract is not commonly provided). The somewhat common use of select value or zero can also be replaced with a simple AND.
[snip]
> The best thing about alpha approach is that its reusing the normal register renaming hardware to
> conditions. No matter what many software people tell you, the key of optimizing is not doing more
> in hardware, the key of optimization is getting rid of unnecessary work. And that is what alpha version
> does. It removes the need for reservation stations to track condition code dependencies.
It might be noted that reading a 64-bit register to get less than three bits of information (Alpha supported test for zero, sign bit set, and least significant bit set in branches) would also be more work. The renaming of a single CC is not that bad, and the dependency tracking does not need to be exceptionally more complex (adding one bit to the CAM of one operand might be a straightforward way of dealing with this; better solutions doubtless exist).
The Alpha design is cleaner in some respects, but it is not clear that it always reduces unnecessary work. In addition, unnecessary work (e.g., speculation which might be wrong) may provide improved performance. (I know this is obvious, but stating such might be useful to some less informed lurker.)
