Hi, I've spent some more time thinking about this and now I've split my proposal into two parts:
http://opencores.org/or1k/Architecture_Specification#Change_Use_of_Carry_and_Overflow_Flags_by_Multiply_Instructions http://opencores.org/or1k/Architecture_Specification#Multiply_and_Accumulate I did this because the first change is actually more of a fix, and has little chance of being disruptive, in my opinion. The first one is also much more important (also in my opinion) as it involves a conflict in the implementation between OR1200 and or1ksim. Ruben has raised this point as well. Implementing the second change would just make the MAC more useful IMO, but it isn't as important as the first. On Wed, Nov 14, 2012 at 3:54 PM, Peter Gavin <[email protected]> wrote: > From looking at the source, it looks like the or1200 does not actually > implement it correctly, because the or1200_mult_mac module only has an > output for OV, not both OV and CY. I believe Ruben verified that it does > not work with his OrBuild tool. > I've double checked this. What exactly happens is that unsigned overflow sets the OV bit, not the CY bit. In fact, it looks to me like the OR1200 does not touch the CY bit except for l.add, l.addc, and l.sub. It appears to set the OV flag for divide by zero, which is also inconsistent with or1ksim. > I'll take a look. I suppose I should check the arch subdirectory of the > linux kernel as well. > I've looked, and it doesn't appear that the kernel uses any mac instructions, nor does it read the MAC sprs using mfspr. (Which is surprising as I would expect the kernel to save them during context switches.) The GCC builtin functions and the code in libgcc do not use these flags or any MAC instructions. > Actually, what I'd like to do now is make l.mulu *only* set the CY flag, > and not even touch the OV flag. > I've changed my mind about this somewhat. I guess l.mulu should clear the OV flag, and l.mul should clear the CY flag. In or1ksim, they are always written together, but some of them (l.div) always set the OV flag to 0. -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
