Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: "Robin Vowels" Newsgroups: comp.compilers Subject: Re: Optimization techniques Date: Tue, 7 May 2019 01:42:36 +1000 Organization: Compilers Central Lines: 65 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-043@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-052@comp.compilers> <19-05-002@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="85130"; mail-complaints-to="abuse@iecc.com" Keywords: errors, comment Posted-Date: 06 May 2019 13:48:17 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2278 From: "David Brown" > On 01/05/2019 03:24, Gene Wirchenko wrote: >> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown >> wrote: >>> If you are writing your code in a "C with the extra feature of having >>> defined behaviour on signed integer overflow", and only compile it with >>> suitable compilers (or compiler flags), then that's okay. But don't >>> call it correct C code and blame compilers for your own mistakes or >>> unwarranted assumptions. >> >> I would like to see it as part of the language. I *know* that I >> want to have an error be thrown at run-time if an error can be >> detected. (It is not an unwarranted assumption.) It is not as if >> detecting signed integer overflow is a difficult thing on, for >> example, System/370, which also dates from 1970. Signed (and unsigned) overflow was around on the IBM 360 from 1965. > Detecting signed overflow at run-time can be a significant cost. Usually not. Even on humble micros, a Junp on overflow or an Interrupt on overflow is usually available. On the S/370 that was mentioned above, and the S/360 before it, and later machines in that family, an overflow is detected by hardware. Extra instructions are not required to detect the overflow. (They can be, if the user desires to process them him/herself.) > It > ruins expression manipulation, optimisation, and simplification - much > more than making signed overflow be two's complement. Even compared to > a dumb translation compilation of expressions, it nearly doubles the > size of the code on many processors as you have to follow each > arithmetic instruction with a "jump if overflow". A jump on overflow is usually a short instruction, less than the length of instruction(s) that generated the overflow. > (Some cpus have > "trapping" arithmetic instructions, but certainly not all.) On small > processors, this is all a heavy penalty on performance. On big > processors, simple instructions are often "free" while the cpu is > waiting for memory reads, but these sequences thrash your branch > prediction buffers. Again, on the S/370 et al already mentioned, no extra instrucions are required to test for overflow. Branch prediction is irrelevant in the event of an overflow. To proceed with the computation is pointless. > No, throwing an error on overflows is not hard - but it /is/ costly. It > can be a marvellous tool during testing and debugging, and may be worth > leaving active in some programs, but it has a price. The "price" of leaving in checks (active or otherwise) is small compared to the human time wasted in tracking down a bug in a program -- whether it is overflow or some other computational error. [IBM mainframes have integer overflow traps, but the Intel micros that most of use do not. There's an overflow flag but the only way to act on it is to put a conditional branch after each instruction that might overflow, which could make things a tad bulky and sluggish. Maybe that's worth it, but it's far from cheap. -John]