Hardware divide and SQRT

After spending a long time with the x86 architecture and now looking at the
Intel Itanium, I have become quite curious about the issue of division and
square-root in FP hardware. I have been programming for over 20 years and
also have training in VLSI design (albeit over a decade ago :( ). So that
said, can anyone here give a "ball-park figures" answer to the following
questions:

(a) If one were to throw silicon at a problem and create a IEEE compliant FP
hardware divider (I believe they are called cell array dividers, though
there may be other kinds) that is as fast (or not far off) as a multiplier
of the same number of bits, roughtly how much extra silicon would it consume
compared to the multiplier? 2x? 3x? 10x? Soccer pitch? :)

(b) If one were to instead turn that on its head and use the same amount of
silicon (or thereabouts) and tolerate some multi-clock implementation,
roughly how many clock tics would be needed?

(c), (d) - the same questions for SQRT.

(e), (f) - the same questions for REMAINDER

NB: For (a), (c) and (e) I mean an implementation having no software, not
even microcode, just a pure VLSI logic circuit. Is that even possible for
SQRT and REMAINDER or would the amount of logic be just stupidly high for
those, as I suspect?

I realise that any answers will of necessity be approximate and probably
simplistic, but that's OK; this is not part of a real chip or anything like
that, I'm just curious as to how far pure hardware division, SQRT and
remainder can be taken if the silicon budget is there.

TIA
--
Martin Howe
Webmaster and Kitten Registrar
Bombay and Asian Self Breed Club
www.bombaybreedclub.org


.

Relevant Pages

  • Re: Hardware divide and SQRT
    ... >square-root in FP hardware. ... >If one were to throw silicon at a problem and create a IEEE compliant FP ... >there may be other kinds) that is as fast as a multiplier ... - the same questions for REMAINDER ...
    (comp.arch.arithmetic)
  • Re: Curse all linuxheads
    ... >memory set up such that there are areas with "trusted" code, ... but you have access to the hardware. ... >> silicon to give up its contents is harder than the average bear. ... >It won't be an on-chip decryptor, but it will be silicon, as I said ...
    (alt.sysadmin.recovery)
  • Re: Curse all linuxheads
    ... > has to be a) small for performance reasons and b) you can always grab it ... > at some point since you have the hardware and the software and it has to ... memory set up such that there are areas with "trusted" code, ... It won't be an on-chip decryptor, but it will be silicon, as I said ...
    (alt.sysadmin.recovery)