(I forgot to add both openrisc lists, if you missed part of this convo because of that, I apologize.)
On Fri, Nov 9, 2012 at 3:13 AM, R. Diez <[email protected]> wrote: > Yes, my OR10 CPU implements them correctly and the Test Suite in orbuild > does test them too. But that's a recent development, I would be happy to > change it if necessary. > Ok, I'm interested to see how you get both flags from one multiplier. > > Would anyone be bothered if the CY flag was never set by the l.mul and > l.mulu instructions, > > and instead, the OV flag was set for signed overflow in the case of > l.mul, > > and for unsigned overflow in the case of l.mulu? > > I think the best fix would be to add a separate trap for the CY flag, as > there may be other instructions where we want to catch unsigned overflows > too. But your suggestion is a good compromise for l.mulu. When you say "CY > flag never set", do you mean it should always be reset, or just left > untouched? > I mean just to leave the CY flag untouched. My two biggest concerns are that I don't know why one would care about unsigned overflow when doing signed multiply, and it's not really easy to implement, especially if you want to use FPGA DSP slices. And I figure it's best to just use the OV flag in both cases so OVE can be used to trap it. I mentioned adding an instruction to do a full 32x32-to-64 multiply, and I've done so on my version of the toolchain. I've actually added a few, now I have a total of 6 instructions under the MAC opcode: l.mac, l.msb: as before, but do a full 32x32-to-64-bit multiply, and don't truncate the product to 32 bits before adding/subtracting l.macu, l.msbu: like l.mac/l.msb, but do an unsigned multiply instead l.mulf, l.mulfu: do a full signed/unsigned 32x32-to-64 bit multiply, storing results to MACLO/HI And I've changed the GNU simulator l.mul/l.mulu only set the OV flag, and only do it for signed/unsigned overflow, respectively. I plan to do the same for or1ksim. This set of 8 multiply instructions can all be implemented through a single 32x32-to-64-bit multiply-add unit, which is how my core will implement it. This pretty much summarizes my planned changes. If anyone has concerns with this so far, let me know. I'm going to write up something on the wiki about it soon, but I don't want to step on anyone's feet WRT already published software that depends on existing behavior. -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
