Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Date: Fri, 10 Jan 2014 23:08:09 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 53 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-01-011@comp.compilers> References: <13-11-025@comp.compilers> <14-01-007@comp.compilers> <14-01-008@comp.compilers> NNTP-Posting-Host: lnews.iecc.com X-Trace: leila.iecc.com 1389630849 74633 64.57.183.51 (13 Jan 2014 16:34:09 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 13 Jan 2014 16:34:09 +0000 (UTC) Keywords: arithmetic, standards, C Posted-Date: 13 Jan 2014 11:34:09 EST 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:1078 Kaz Kylheku wrote: > On 2014-01-08, Ivan Godard wrote: (snip) >> I am such a CPU designer. We faced the "undefined" issue in our Mill >> family of general-purpose CPUs (ootbcomp.com). Not only are languages >> under-constraining, they are also sometimes over-constraining: signed >> integer overflow is undefined in C but required to wrap in Java. > It's only undefined on paper. In reality, if you don't make it > wrap in C like in Java, unknown numbers of C programs will break, > and not all of them doing it by accident. Well, C has unsigned with defined wrap on overflow. C still allows for ones complement or sign magnitude along with the more usual twos complement. As I understand it, Unisys still sells some ones complement machines. I am still waiting for a C compiler for the 7090 to test out sign magnitude in C. Java doesn't have the unsigned types, except for 16 bit char. Some that might have been done unsigned in C, can be done with that appropriate wrap of twos complement Java. >> Our solution was to offer four hardware "overflow-behavior" options for >> every operation for which overflow is possible: modulo (wraparound), >> excepting, saturating, and double-width result (which cannot overflow). It has been hardware tradition for a long time to offer double width product on multiply and dividend on divide, but rare for high-level languages to allow for its use. I believe that gcc recognizes casts to (long long) on the operands of multiply to generate a single multiply instruction with a double length product. (That is, it doesn't do the three multiplies by zero that the casts imply.) I don't know about divide. I have at times needed to multiply two 32 bit values, for a 64 bit product, then divide by another 32 bit value. I sometimes hope that the compiler figures it out. (snip) > This kind of thing is quite useful for optimizing certain code. > For instance, fixed-point implementations of codecs, in which > reproducing bit-exact results over the test vectors requires > "saturation" treatment of overflow. Clamping the results in > software adds many additional cycles. I have also worked on some dynamic programming algorithms that require saturating arithmetic. I believe that Intel SSE allows for it, but it is rare for normal CPU instructions. -- glen