On Wed, Oct 3, 2012 at 2:58 PM, R. Diez <[email protected]> wrote: > I just had a look at Xilinx' LogiCORE IP Multiplier v11.2, and it does not > seem able to generate a multiplier with a sign selection input signal, which > is rather unfortunate. I'll take a look later at the macro library functions, > but if the generator does not offer that function, I doubt I'll find > something better in the library.
You can do an unsigned multiply on a signed multiplier by padding the inputs with a sign bit. So just make it infer a 33x33->66-bit multiplier when you use Xilinx. > >> [...] >> Then we could add 2 opcodes, l.mulf and l.muluf (for multiply-full & >> multiply-unsigned-full) that dump their results in the HI and LO >> registers. >> [...] > > Those new opcodes would be an advantage for CPUs that implement the l.mac > instruction. However, for other CPUs, I would just let l.mul/l.muli/l.mulu > write the high 32 bits to some new Special Purpose Register. Old software > wouldn't be affected by this change, and new software can take advantage of > the extra bits. The reason I suggested adding opcodes for that and reusing the MAC registers is that it reuses the datapath, and only changes the control logic a bit and some decoding logic. Adding a new register requires the new flip flops, and adds another fanout to the output of the multiplier, which could impact timing. > > In any case, the main issue is the Carry flag for the signed multiplication > instructions. I'm not an expert at 2's complement, but it's becoming clear > that, if you multiply signed integers (or use the signed mode of some > all-purpose multiplier), it's easy to calculate the Overflow flag, but it's > not easy to calculate the Carry flag as if you had multiplied unsigned > integers in the first place. We don't want to multiply both ways like or1ksim > does. > > Let's change or1ksim's behaviour and the Test Suite so that the signed > multiplications always clear the Carry flag. The multiply instructions would > look like this: > > 1) l.mulu sets the Carry flag when necessary and always clears the Overflow > flag. This is the existing behaviour. > 2) l.mul and l.muli set the Overflow flag when necessary (existing behaviour) > and always clear the Carry flag (modified behaviour). > > Do you agree with that change? That would mean modifying your copy of or1ksim > (your task) and orbuild's test suite (my task). How would that solve the problem? You still need a multiplier that can do both signed and unsigned multiply, if you want to keep the high bits. I mean, assuming you have a 32x32->64-bit multiplier with an signed/unsigned switch, the rest isn't that difficult to implement. And if you are able to infer a signed multiplier of any width (which the Xilinx one will) you can still fake it. On the other hand, I do agree that it's strange to emit unsigned overflow when doing signed multiply. -Pete _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
