Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer,comp.lang.c Subject: Re: Arithmetic overflow checking Date: Mon, 11 Jul 2011 21:51:28 -0400 Organization: A noiseless patient Spider Lines: 42 Message-ID: References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> <3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com> <1d742049-31f6-4eb6-8832-9cce3f25091d@a31g2000vbt.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 12 Jul 2011 01:52:25 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="BrOwaJANne849xlH+KPYjQ"; logging-data="10906"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Mcbr7pyiMdoD+0EGpQKxU" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 In-Reply-To: <1d742049-31f6-4eb6-8832-9cce3f25091d@a31g2000vbt.googlegroups.com> Cancel-Lock: sha1:uoAyL3+XkQSWpwauPuMnUl8heQ8= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6095 comp.lang.c:8147 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