Path: utzoo!mnetor!uunet!husc6!bbn!rochester!udel!burdvax!sdcrdcf!ism780c!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: The need for D-scussion (was Re: D Wishlist)
Message-ID: <3073@haddock.ISC.COM>
Date: 20 Mar 88 20:07:06 GMT
References: <12176@brl-adm.ARPA> <1988Mar11.215238.976@utzoo.uucp> <3732@bloom-beacon.MIT.EDU> <7451@brl-smoke.ARPA> <27143@linus.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 17

In article <27143@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
>I am a computational number theorist who writes a LOT of code requiring that:
>A*B/C [and] A*B%C be computed where A,B,C are all 30 bit quantities.  The
>difficulty is that even though the algorithm guarantees that the results of
>the computations fit in 30 bits, the product A*B may not. I therefore need to
>make extensive use of any 'emul' and 'ediv' facilities that a computer may
>have. ... Machines which have such instructions should, In my opinion,
>generate emul/ediv code whenever it sees A*B/C and only return a run-time
>arithmetic overflow if the quotient doesn't fit in the appropriate word-size.

Such a special case would be a wart in the language.  The "correct" way to do
this is to provide an "lmuldiv" function which has the desired semantics (I'd
have it return an ldiv_t structure, since it already exists in ANSI C), and
encourage vendors to give their compilers the ability to inline it (along with
other trivial functions, such as abs()).

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint