Re: ANSI portable overflow detection

hbaker@netcom.com (Henry G. Baker)
Fri, 13 May 1994 16:13:01 GMT

          From comp.compilers

Related articles
ANSI portable overflow detection davids@ICSI.Berkeley.EDU (1994-05-12)
Re: ANSI portable overflow detection upton@quip.eecs.umich.edu (1994-05-13)
Re: ANSI portable overflow detection hbaker@netcom.com (1994-05-13)
Re: ANSI portable overflow detection Roger@natron.demon.co.uk (1994-05-18)
| List of all articles for this month |

Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Keywords: arithmetic
Organization: nil
References: 94-05-039
Date: Fri, 13 May 1994 16:13:01 GMT

davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) writes:
>[can I check for overflow on integer multiplies in ANSI C in a
>portable and efficient way?]


It ain't easy to do this _portably_ in most HLL languages. The HW folks
go to a lot of trouble to provide efficient multiple precision
capabilities, and then for some reason the language/compiler folk proceed
to ignore them. I have made myself hoarse over the years arguing for
portable multiple precision primitives in non-assembly languages. I think
the basic reason for their lack, is that the compiler people don't give a
s**t about arithmetic, except for floating point arithmetic, which pays
their salaries, since they don't use it themselves. (This part is obvious
from the poor decimal conversion routines usually provided; Ada being the
outstanding exception, with its requirement for _exact_ compile-time
arithmetic.)


The biggest problem seems to be that multiple precision multiplication
requires _two_ results, and since this doesn't mesh well with HLL's single
function result, they just ignore it. Problem solved; case closed.


The other problem is that these multiple precision primitives are
worthless unless they are _fast_, so providing standard out-of-line
library functions doesn't really solve the problem. The correct solution
is to bite the bullet and include special syntax just for these
primitives, or if you care about elegance, then provide a more
interesting&efficient mechanism for multiple values in the language &
calling sequences.


If anyone is interested, the following article touches on one problem:


Baker, H.G. Computing A*B (mod N) Efficiently in ANSI C. ACM Sigplan
Notices 27,1 (Jan 1992), 95-98.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.