Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking Date: Fri, 08 Jul 2011 00:30:01 -0400 Organization: A noiseless patient Spider Lines: 32 Message-ID: References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 8 Jul 2011 04:30:35 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="BrOwaJANne849xlH+KPYjQ"; logging-data="14386"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ljtrvvHDre0aicSyJ1kEa" 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: <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> Cancel-Lock: sha1:VxhlwzfbTQUYbHhuQHaWUbmUbOk= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5979 On 7/7/2011 8:51 PM, Peter Duniho wrote: > [...] > I would not worry about the "simple" or "efficient" criteria. IMHO, if > one is deciding to apply overflow checking to every computation, one has > already abandoned the hope of efficiency. I've used machines that raised overflow traps "for free," in the sense that it was done by the hardware/firmware/microcode, just like setting condition flags. Flipping the mode bit that enabled or disabled traps for integer arithmetic was relatively expensive, so programs tended to set it one way or the other during initialization and then just leave it alone. But it's not necessary to use a global bit to get this kind of behavior: an instruction set might feature both an AddAndWrap and an AddAndTrap instruction. True, that's not entirely free -- you pay for extra decoding logic in the instruction pipeline, for example. But the inefficiencies don't rise to the "abandon hope" level, IMHO. Besides: What are the relative efficiencies of an error caught and announced versus a wrong answer computed at great speed without any indication that it's wrong? (The machines I speak of were from forty-odd years ago and might be dismissed as ancientry, but their lineal descendants are still being made and sold. I don't know how today's editions deal with overflow, but if you're curious you can write to the vendor. Their headquarters are in Armonk, NY.) -- Eric Sosman esosman@ieee-dot-org.invalid