On Thu, Nov 29, 2012 at 12:00 AM, Peter Gavin <[email protected]> wrote: > On Mon, Nov 26, 2012 at 5:56 PM, Julius Baxter <[email protected]> > wrote: >> >> Well, how about a neater suggestion, which is not to modify the SR, >> >> but instead make the OVE bit control whether any of the arithmetic >> exceptions occur, as specified in the AECR. So "OVE" comes to mean >> "enable exceptions for all of the overflow, signed or unsigned, >> situations set in the AECR" but the OV bit then indicates signed >> overflow and CY unsigned. Then, any overflow or carry sets the OV or >> CY bit as necessary, and triggers an exception depending on OVE and >> the bits in AECR. I should think DBZ can set OV for l.div and CY for >> l.divu, causing an exception for either if DBZE is set in the AECR. > > > Yeah, I think I was just having trouble understanding what you were saying, > but it sounds good. > > Could you flesh out the wiki entry on the proposal a bit better, and maybe > add lists of instructions that are affected, along with the current behavior > vs. new behavior? I know that's probably quite a bit of work, but will help > ensure we're not breaking the ABI.
Fair call. Check it out: http://opencores.org/or1k/Architecture_Specification#Control_of_Carry_and_Overflow_Flags_and_Exceptions > > Also, what are we going to do about the multiply OV and CY flags? I still > think we should remove the requirement that l.mul detects both signed and > unsigned overflow at the same time. The problems I have with that > requirement aren't really related to exceptions. I'd prefer that l.mul and > family be implementable with a stock multiplier (e.g. using the '*' > operator), instead of requiring a hand coded one. I know I'm repeating > myself, but the OR1200 doesn't even get this part right, and it means you > can't easily use DSP slices. (I suppose there might be some creative use of > DSP slices that would implement it correctly, but it's not exactly > straightforward, and would likely have to be tuned to the particular FPGA.) > Also, it makes l.mulu completely redundant, since it's *identical* to l.mul, > but always sets the CY flag to zero. Since we have l.mul and l.mulu I think it's fine that l.mul flags signed overflow and l.mulu flags unsigned overflow (carry.) I've also rolled in support for overflow detection in the MAC, according to your new proposal (which seems sane to me, we haven't had much discussion, but I reckon it looks right.) If people are happy with this I'll roll another arch spec draft, which should be close to, if not, the final 1.0 version. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
