On Sat, Nov 17, 2012 at 7:38 AM, Peter Gavin <[email protected]> wrote: > 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. >
Hi Pete Thanks for the suggestions. It's good to see a solution to these carry and overflow issues being thoroughly fleshed out. 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 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 [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? As you know, I'm in architecture spec update mode at the moment, and we could roll this in if we all agree it's going to give us good guidelines to fix up the various implementations. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
