On Tue, Nov 20, 2012 at 5:50 PM, Julius Baxter <[email protected]>wrote:
> Jeremy has pointed out, though, that you may not want to be triggering > carry exceptions for basic additions, which is going to happen if CYE > is set to catch the useful case of an unsigned multiply overflow. See > his post on the architectural discussion page here: > > http://opencores.org/or1k/Talk:Architecture_Specification#Change_Use_of_Carry_and_Overflow_Flags_by_Multiply_Instructions > > Ah, yes, I'll admit I might have misread some of the things he said. I've been way too busy recently and trying to keep up with about 3 or 4 projects at the same time, not to mention moving in a roommate and dealing with other, ehm, stressful situations. So I apologize if I've missed a few things. :) I have followed on with a suggestion that perhaps we implement a basic > mechanism, similar to the floating point unit, which provides fine > grain control over what arithmetic cases cause an exception: > > I propose: > > Arithmetic Exception Control Register (AECR) > > A 32-bit R/W SPR to control which arithmetic conditions will trigger a > range exception > > [0] CYADDE > Carry flag set on add/addi/addc/addic/sub causes exception > [1] CYMULE > Carry flag set on mulu causes exception > [2] OVMULE > Overflow flag set on mul (MAC, too?) causes exception > I don't believe the MAC ever touches the flags, but I think it probably should. The current MAC can actually overflow the multiplier *and* the adder. So that's actually two sources of overflow to worry about. > [3] DBZE > Divide by zero causes exception > > Arithmetic Exception Status Register > > A 32-bit R/W SPR to indicate which arithmetic conditions triggered a > range exception. Write 1 to the bit to clear it. > > [0] CYADDE > Carry flag set on add/addi/addc/addic/sub caused an exception > [1] CYMULE > Carry flag set on mulu caused an exception > [2] OVMULE > Overflow flag set on mul (MAC, too?) caused an exception > [3] DBZE > Divide by zero caused an exception > > The SR could have its OV and OVE flags changed to simple an Arithmetic > Exception Enable (AEE) bit which causes exceptions to occur as > dictated by the AECR. That's probably breaking the ABI though, so I > guess we add another bit for AEE and on CPUs with the OV flag we > indicate that it's deprecated and they should use the AECR and AESR > and SR[AEE]. > > There may be additional overflow/carry conditions I have missed above, > but I think this basically covers it. > > What do you think? > Maybe I'm missing something, but why not OVADDE? Also, you don't need to *change* OV/OVE to AE/AEE, you can just *add* the AE/AEE flags, and leave the OV/OVE/CY/CYE functionality exactly as it is now. Then you make the AECR default to 1s everywhere, and have each bit be ANDed with CYE/OVE as appropriate. Then to use the new functionality you still have to turn on the OVE/CYE bits, but then you turn off AECR bits to get only the exceptions you want. This way, nothing has to be deprecated :) Otherwise, this looks very good. -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
