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). 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 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. Thanks, rdiez _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
