Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.palinacquisition!news.posted.palinacquisition.POSTED!not-for-mail NNTP-Posting-Date: Fri, 08 Jul 2011 03:29:20 -0500 Date: Fri, 08 Jul 2011 01:29:20 -0700 From: Peter Duniho User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: Lines: 56 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 50.46.118.188 X-Trace: sv3-LBoXc+t1dUOTXCXuWu4ImjIr1CHBXwZLlWVqPoVyg7SzcFJ+e0B2hu6Mah+suhaL4I+Zyp6negARuld!APwonkVuW24HFhirqMXHxEW4FNMqF5yVYHbyIndql24QDTKm4RCUmSnhYdb1+yqCfmiIPJ/Wf8u5!JXW6Z2awMkb1ixkw0h/9+8L9jaRxJxfEEkYrGPlTZLE= X-Complaints-To: abuse@iinet.com X-DMCA-Complaints-To: abuse@iinet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4441 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5985 On 7/7/11 9:30 PM, Eric Sosman wrote: > 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. AFAIK, mainstream hardware (e.g. x86-compatible) doesn't include special overflow-checking instructions as you're describing. I agree it's theoretically possible, but without such instructions in actual hardware, one is left toggling global state around every place that involves a change in whether overflow is checked or not. Maybe some of the other more common CPUs, such as PowerPC, SHx, ARM, etc. do include those instructions. I don't know off the top of my head. But targeting a specific CPU would still require JVM and/or bytecode support. These are hypothetical solutions, even more hypothetical than the actual question. :) (In case it's not clear, I should emphasize that my comments are in the context of the stated question…that is, assuming Java as it is today, and potential solutions given the stated requirement). > 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? You'll get no argument from me there. I'm a strong proponent of correct code over incorrect fast code, and even of correct, _maintainable_ code over correct fast code (at least prior to detailed performance analysis). In fact, my main point was that given the stated requirement, worrying about efficiency becomes beside the point. If you have a business need for having every computation checked for overflow, then you have that need, whether or not it can be done efficiently. If one can find an efficient solution, great. But I think given what the OP has to work with, that's not likely. More important just to get _some_ working solution (assuming it's a real requirement…as I mentioned, I suspect it's not as hard-and-fast as the original question seems to imply). Pete