Obscure C code (was Re: Excessive optimization)

[Chuck Guzis]

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