2 Dec
2010
2 Dec
'10
7:53 p.m.
On 2010 Dec 2, at 7:35 PM, Chuck Guzis wrote:
On 2 Dec 2010 at 21:03, Brian Lanning wrote:
The notion of integer divide is pretty well defined. I'd be pretty
annoyed if I specced two ints, did a divide and didn't get back the
'standard' result. I don't have a C ref at hand, but in C at least, I
think it would be stretching acceptable claims of language flexibility
or non-specification for compiler implementors to be taking leniency
here.
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.