Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!amdcad!jetsun!weaver
From: weaver@jetsun.weitek.COM (Mike Weaver)
Newsgroups: comp.arch
Subject: Re: standard extensions
Message-ID: <1991Feb27.183718.638@jetsun.weitek.COM>
Date: 27 Feb 91 18:37:18 GMT
References: <1991Feb25.135057.23667@linus.mitre.org> <1991Feb25.201406.18643@bingvaxu.cc.binghamton.edu> <2124@cluster.cs.su.oz.au> <1991Feb27.021435.11296@bingvaxu.cc.binghamton.edu>
Reply-To: weaver@jetsun.WEITEK.COM (Michael Weaver)
Organization: WEITEK, Sunnyvale CA
Lines: 19

In article <1991Feb27.021435.11296@bingvaxu.cc.binghamton.edu> kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell) writes:
>In article <2124@cluster.cs.su.oz.au> rex@cluster.cs.su.oz (Rex Di Bona) writes:
>Oh, I don't know. I kinda had the impression that there were some
>high performance divide pipelines that did give a result every cycle.
>Milage may vary however. (Perhaps giving example 68000 code was a bit
>misleading).
>
>-kym

Does anyone know of a pipelined divider that gives a result every cycle?
As far as I know, they exist only on paper, and for good reason:
every algorithm I have heard of for an 'array' divider starts with
an iterative algorithm, and simply repeats the hardware for each 
iteration. This means that the amount hardware is increased by 
the same factor as the increase in throughput, and the latency 
remains the same, which is not very attractive. Also, the actual
number of transistors is horrendous -- it would take perhaps
ten times as many transistors as an array multiplier, which
is a large thing.