The need for D-scussion (was Re: D Wishlist)

[Robert D. Silverman]

In article <7451 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <3732 at bloom-beacon.MIT.EDU> tada at athena.mit.edu (Michael Zehr) writes:
>>a function the returns both a % b and a / b at the same time.
>
>This is the first time I recall in the "D" discussion that an useful
>genuine language feature has been proposed.  All you need now is a
>suitable notation..


I am a computational number theorist who writes a LOT of code requiring
that:

A*B/C
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. I have written code which spends 25% of its time JUST
doing the above computations (and takes 100's of hours to run).
Since there is no 'long long' in C I am forced to write an assember routine 
which does the computations as follows:

remainder = mod_mult(A,B,C,&quotient)

or the equivalent depending on circumstances. It must first emul A and B
then ediv by C. Since most machines which have ediv return the quotient and
remainder in two different registers no extra work is required to get the
remainder after doing the division.

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. There
should at least be some compiler switch which allows this option. What good
are emul and ediv if you can't reach them from higher level languages?
Especially on a VAX if you have to call an assembler routine to perform
the above, the subroutine call itself can take about as much time as the
calculations. A calls on the VAX/780 with 4 arguments takes ~ 17usec.
The ediv takes 11.9 and the emul takes 6.8usec. UGLY.
 
There is some need (although I will concede not a lot) for multi-precision
arithmetic support. Modern languages are woefully inadequate for the task.


Bob Silverman