On Tue, Nov 20, 2012 at 11:49 PM, Peter Gavin <[email protected]> wrote: > 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: >>
Hi Pete, >> >> 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. OK, the MAC's operands are always considered signed, so let's have it effect the OVMULE and the signed addition overflow bit (something which is missing in this proposal, as you mention below.) > >> >> [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? OK, well, I'm a bit confused here. You're right, clearly we need a way to indicate signed overflow of addition/subtraction, but there's an inconvenient aspect to OR1K's ISA. It goes to Jeremy's point that you will have to manually enable or disable the exceptions as the interpretation of your operands changes. For example, you care about both unsigned and signed overflow, but OR1K doesn't have explicitly signed or unsigned addition and subtraction instructions, so if your number is intended to be signed but triggers an unsigned overflow (-1 + 2 = 0xffffffff + 0x00000002 = 0x00000001 + carry) you will need to disable the CYADDE before you run that instruction. But be that as it may. > > 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 :) There is no CYE bit at present, only OV, OVE and CY. 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. How does that sound? Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
