Re: Arithmetic overflow checking
On 7/11/2011 5:54 PM, tm wrote:
[...]
Correct results can be computed without any slowdown,
when the CPU is able to trigger an overflow interupt.
A slowdown would only happen when an overflow occurs.
Computations without overflow would run at full speed.
Well, no. At least, not in any trap-capable architecture I've
seen. Three points:
1) Even the non-trap isn't entirely free: There's some logic in
the execution pipeline that decides not to raise it. The silicon
devoted to that logic might instead have been devoted to one more
slot in a CPU-internal cache or something, so its mere presence slows
down the CPU even if it's never exercised.
2) In mode-bit styles, the maintenance of the mode bit carries
a cost. You've got to set or clear it before some computation, and
restore it afterward, and the instructions to do so aren't free. In
the machine I mentioned earlier, the mode bit was in a "Program Status
Word" that was mostly off-limits to user-level code; IIRC you had to
call an O/S service to fiddle with the bit. (It's been a long time and
maybe I don't RC, but if there were special instructions to manipulate
the privilege-insensitive parts of the PSW, see point (3) below.)
3) In ISA styles (different instructions to wrap or trap), you
double the "decode space" for the instructions of interest. That is,
the arithmetic instructions need to devote a bit to wrap/trap, and the
bit therefore becomes unavailable for other purposes. This means that
some otherwise desirable instructions will be absent from the ISA, and
that programs desiring those operations will perforce execute multiple
instructions instead of just one.
These effects are all small (I think). But in an environment where
a 3.63GHz part gets bragging rights over a mere 3.59GHz, I don't think
"full speed" is entirely accurate. It's sort of like those car ads:
"Best highway mileage *in its class*."
--
Eric Sosman
esosman@ieee-dot-org.invalid