> 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.
I see. I haven't implemented the MAC instructions yet on the OR10 CPU. Does the current GCC take advantage of l.mac if available? > 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. That's not the problem. The problem is that, no matter what multiplier strategy you choose (inferred, macro, manually sign-extend, etc), a multiplier will do either a signed multiplication or an unsigned one, but not both at the same time. However, the current l.mul / l.muli instructions on or1ksim calculate the Overflow flag as if the operands were signed integers, and the Carry flag as if the operands were unsigned. You need to multiply both ways (signed and unsigned) in order to generate both flags. This is the extra burden I'm trying to avoid. Regards, rdiez _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
