> You only need one multiplier to do both signed and unsigned. 32x32 ->
> 64-bit multiplication is identical whether the operands are to > interpreted as signed or unsigned, as long as you interpret the result > the same way. So all you need to worry about is the CY and OV bits if > you use a full multiplier. Is there an example somewhere where I could copy the CY and OV logic from? I don't really want to become an expert in this subject. 8-) > If we sign extend -2 and -3 all the way out to 64-bits, this is the result: > fffffffffffffffe x fffffffffffffffd = 0000000000000006 > This is what a signed multiply does. > > If we truncate those values to 32-bits, then multiply, this is the result: > 00000000fffffffe x 00000000fffffffd = fffffffb00000006 > This what unsigned multiply does. Do you mean I should sign-extend to 64 bits and do a 64x64->64 multiplication? Does that need more resources than a 32x32 -> 64 multiplication? Are you sure the multiplication works exactly the same? I wonder why there are separate opcodes for signed and unsigned multiplication then in the 8086 architecture. >> I was also planning to add a Special Purpose Register and store the > high-order 32 bits from the final 64-bit result, as discussed in this Forum a > few days ago. If I had to calculate the full 64 bits, I might as well make > them > all available to the software. > > I wouldn't suggest this. I think we should leave the current opcodes > the way they are. Then I'd add another multiply opcode that drops > the result in the MACHI and MACLO registers. If you want the high > part you'd have to use a mfspr instruction. I also think we should > fix the MAC to do a 32x32-bit to 64-bit multiply, and use a full > 64-bit add. If I have to calculate the full 64 bits for CY and OV purposes, I may as well store the high part in a new SPR. That wouldn't affect any software that uses the old opcode and doesn't know about the new SPR, does it? If I implement a new opcode like l.mul64, I need to support both the old and the new opcodes, which would waste a few extra resources, wouldn't it? > The comment indicates the Carry flag interprets the operands as > unsigned values. In this case, -2 and -3 are actually very large, and > multiply out to a number that's larger than what can be stored in 32 > bits. So I think or1ksim is correct in this case. That's right, but, like I said in my previous e-mail, the documentation for the l.mul instruction specifies that both integers should be treated as signed integers. There is another opcode for unsigned multiplication, "l.mulu". Why would we want to set the carry flag for l.mul as if the integers were unsigned then? Thanks again, rdiez _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
