> Computing 1/x on an integer unit yields 0 for every abs(x)>2 at least,
> or am I missing something? You can do such tricks with precomputing
> b/x for a known b (e.g. 2^16) and dividing that b off later, but that
> is, strictly speaking, fixed point arithmetic.
>
> > And of reasons, why the lack of integer division instruction
> > at Alphas is not a bad thing in my opinion.
>
> That's another issue. Yes, a hardware division engine breaks
> pipelining and the operation is much more rare than multiplication, so
> the trade-off is completely valid.
That's why MIPS CPUs don't process integer multiply/divide in the normal
integer pipeline. These operations are being processed in a separate
execution unit that writes it's results into a pair of extra registers.
The integer pipeline stalls only when code attempts to access these
extra registers before the operation is finished. The stall can be avoided
by correct instruction scheduling (which GCC ins't too good at ...)
This makes sense because the integer multiply/divide operation is much slower
than the floating point operations. Floating point multiply again is
that fast (The R4000 can start a multiply every 3 cycles) that the real
problem is often supplying the FPU with enough data to process.
Anyway, the general tendence that fp performance grows faster than integer
performance seems to continue and therefore I don't recommend trying to
convert floating point operations into integer operations for any
architecture. This isn't too nice to old iron but ...
Ralf