Re:The Performance Cost of Integer Overflow Checking
by solarexplorer on Thursday December 18, 2014 @04:35AM
(#8766625)
If you assume that reading (and clearing) the Q bit is infrequent, you can do something much cheaper. Because the bit is sticky, the order in which you set it does not matter. And when you need to read (or to clear) the Q bit, you just block the instruction that wants to read/clear until the OoO core is empty.
[ Parent
| on HN ]
Re:The Performance Cost of Integer Overflow Checking
by Tuna-Fish on Thursday December 18, 2014 @05:21AM
(#8766724)
An OoO core with speculation has to be able to roll back arbitrary instructions when an earlier instruction causes a visible trap after a later instruction has been executed. Because of this, the core needs to be able to reconstruct the value of Q at any point of execution, even if it's not actually needed then. So the order matters.
Re:The Performance Cost of Integer Overflow Checking
by solarexplorer on Thursday December 18, 2014 @05:33AM
(#8766741)
Good point. So then instead of updating Q out-of-order you could update at commit. You just need to block any instruction that reads Q until the OoO core is empty. This is _much_ cheaper to implement than adding a dependency on all instructions.