2 Dec
2010
2 Dec
'10
7:35 p.m.
On 2 Dec 2010 at 21:03, Brian Lanning wrote:
My guess is that most C programmers wouldn't know
that the divide
operator in C takes floats as parameters. The compiler does an
implicit conversion from into to float on x and y, does the divide on
the floats (hence floating point exception), then converts the value
back to an int for storage in z.
It's certainly the case that many architectures lack a fixed-point
divide--or a floating poit divide (see, for example, the i860 or Cray-
1 with the floating reciprocal approximation), but conversion to
float then division, then conversion back to int is an implementation
decision rather than a C requirement.
This can lead to some interesting issues. On the CDC Cyber 70/170,
an integer divide was usually done by performing an unnormalized
floating divide and recovering the low-order result (also
unnormalized). This worked well, but an integer was 60 bits, and the
divide operated only on 48 of them. So you could get some very odd
answers with large numbers.
Moral: Always be aware of implementatin details.
One particularly ugly implementation detail I recall from
Lattice/Microsoft 16-bit C was the division of a long int (32 bits)
by a long int. The run-time employed a very slow shift-and-subtract
(paper-and-pencil long division) routine to perform the task.
On the other hand, if one was expecting a 16-bit quotient and had a
16-bit divisor, a 32-by-16 bit could be performed by calling a
library routine and was *much* faster.
--Chuck