🚀 go-pugleaf

In article <CLIFFC.95Oct5082046@ami.sps.mot.com>
           cliffc@ami.sps.mot.com "Cliff Click" writes:

>> This replaces 1 division operation with, at a rough count, 17 'fast'
>> operations. While this may be faster on many systems it would be unwise
>> to assume it.
>
>Humm, lemme put on my compiler hat, and rewrite this a bit, pretending
>I'm on a dual-integer-issue machine that supports dependent adds
>(which include some Sparcs & Alphas, probably HP & PowerPC as well):
>
>t1  = x & 0xfffff
>t2  = x >> 20        - Cycle 1
>t3  = t1 + t2 + 1    - Cycle 2
>t4  = t3 & 0x3ff
>t5  = t3 >> 10       - Cycle 3
>t6  = t4 + t5        - Cycle 4 (one instruction issued)
>t7  = t6 & 0x1f
>t8  = t6 >> 5        - Cycle 5
>t9  = t7 + t8        - Cycle 6 (one instruction issued)
>t10 = t9 & 0x1f
>t11 = t9 >> 5        - Cycle 7
>t12 = t10 + t11      - Cycle 8 (one instruction issued)
>t13 = t12 & 0x1f 
>t14 = t12 >> 5       - Cycle 9
>t15 = t13 + t14 - 1  - Cycle 10
>
>Quad issue boxes probably can't do this much faster due to
>dependencies.  However, 10 clocks beats integer divide on many
>machines. 

Agreed but I don't think that is inconsistent with my statement! :-)
Of course the people who should be worrying about this sort of thing
are the compiler writers. 

I don't know what the state of the art is regarding hardware dividers. A
fairly simple one could take 1 cycle per bit in the dividend and leading
0 bits could be optimised out fairly easily. I don't see too much problem
with 2 or possibly even 4 bits per cycle depending on how much silicon you
are prepared to throw at it.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------