On Thu, Oct 29, 2009 at 2:20 PM, Petter Urkedal <[email protected]> wrote: > 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?
That's the point. We have fast dedicated multipliers. But they're limited. So we can reuse the same multiplier for barrel shifts, rotates, alignment for fp adds, integer multiplies, and fp multiplies. I am concerned about the multiplexing requires to route everything in and out of the same set of multipliers, but we don't want to use up our multipliers too fast. > > I would be nice to have 64 bit result just to make the ALU more > complete, if we have a sufficiently strong excuse ;-) -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
