On Mon, May 21, 2012 at 9:52 PM, R. Diez <[email protected]> wrote: > Hallo Julius: > >> You will need to clear the OV flag in the value in the ESR before you >> do the l.rfe or it will keep triggering the overflow exception. > > I haven't had time to look at this in detail, but I thought I'd ask anyway in > the meantime. > > I couldn't find in the architecture specification an exact description of > what should be happening when an arithmetic instruction overflows and > triggers the range exception. Should the instruction complete and store the > (overflowed) result in the destination register before the exception > triggers? Or should the CPU behave as if the instruction didn't execute? If > so, the OV flag should be considered part of the result, and therefore, if > the instruction did not actually execute, this flag should not change either > (atomic operation, all or nothing should be set).
Good point. The behaviour is not clearly defined. I assume it's that the appropriate result is stored, but then the OV flag is set, and triggers the interrupt. As there is more than one cause of a range exception, you need to have the OV flag set to be sure that it was caused by an arithmetic overflow. Then, it's not clear what should happen if you l.rfe with the OV flag set. I argue the simplest interpretation of "Overflow flag causes range exception", as the SR[OVE] bit is defined as, means that when the SR[OV] flag is high (not "goes high" implying edge-sensitive, rather level sensitive) at the same time as the SR[OVE] flag then that triggers an exception. Maybe this is something which could be tidied up in the architecture specification. > > I would think it would be best if the trapped/failed instruction does not > execute at all. That way, the operating system could possibly modify the > software environment and try again. If the failed instruction did modify the > destination register the first time around, re-running it could always lead > to failure, or at least the results may not be repeatable. I can't comment on this. I'm not sure of the common overflow handling techniques in OSes which might run on OpenRISC. > > I guess or1ksim is not setting the overflow flag if the instruction traps, as > I don't recall having cleared the OV flag in the ESR before executing the > l.rfe instruction, and the test is running fine under or1ksim. Perhaps it's emulating an edge-sensitive exception approach. Maybe the original implementers meant this behaviour, but only captured it in or1ksim. Then again, I doubt that there was much thought put into it. So, basically, I don't know, and I don't really mind how we handle OV. But we obviously need a better explanation of the cause and handling of overflow exceptions caused by arithmetic ops. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
