> [...] > Most of the hard macro multipliers I've seen are something like this. > [...]
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. > [...] > 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. 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). All the best, Ruben _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
