On 2009-10-29, Timothy Normand Miller wrote:
> On Thu, Oct 29, 2009 at 7:24 AM, André Pouliot <[email protected]> 
> wrote:
> > Petter Urkedal wrote:
> >> On 2009-10-27, Andre Pouliot wrote:
> >>> 2009/10/26 Petter Urkedal <[email protected]>
> >>>> 2.  Do we need to support extraction of the upper 32 bits of a
> >>>> multiplication?  If not, then mult and umult are also equivalent except
> >>>> possibly for the flags.  I think we can reuse the carry flag for
> >>>> overflow of an unsigned multiplication in analogy to the additive
> >>>> instructions.
> >>>>
> >>> The cost for supporting the selection of the upper or lower part of the
> >>> multiplication is small since we can will probably use a signed 33 bits
> >>> multiplier. Yes it does carry a cost to doing it that way but the 
> >>> multiplier
> >>> will be reuse to do the shift operation in both direction. It should also
> >>> support rotate instruction.
> >>
> >> We have 18 × 18 -> 36 multipliers at our disposal.  A 32 × 32 -> 64
> >> multiplier takes 4 of these, whereas 32 × 32 -> 32 takes 3.  Also the
> >> final adder has the width of result.  So, I think it costs enough that
> >> we should carefully consider whether we need it.
> >>
> > The multiplier serve as a barrel shift for the data alignment of the
> > adder. It also serve for doing right and left shift. If we were only
> > doing the 32 x32 multiplication doing a 32 bit result you would be right.
> 
> Oh, yeah.  I didn't even think about that.  You're right.  Way to
> minimize the logic here!

We're talking about the FP adder here, right?  I haven't started
thinking about sharing between int and FP yet, but in any case, isn't a
barrel shifter a lot simpler that the extra logic required by
32 × 32 → 64 multiply?  Or do the hard-coded units in the FPGA make that
irrelevant?

I would be nice to have 64 bit result just to make the ALU more
complete, if we have a sufficiently strong excuse ;-)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to