DIV by 0
Fabio752 opened this issue · comments
in issue #16 and in every MIPS specs it is clearly specified that the DIV by 0 should NOT throw an arithmetic exception because it should be undefined behaviour.
However, in the specifications given in this repository there is written:
"Arithmetic exception (-10) : Any kind of arithmetic problem, such as overflow, divide by zero, ..."
What should the simulator do then?
The spec includes examples of things that could be treated as arithmetic exceptions. What should is defined by the ISA. #16 clarifies that DIV can never cause arithmetic exceptions, but other divide instructions can.
Just got the same question, I would like to confirm that as by #16, if the spec say no Arithmetic exception (only undefined), we do not need to handle it(any return code is valid), and it is not possible to test such case.
For DIV, any result from division by zero is valid, but that does not mean that any return code is valid: if division by zero causes an exception, that is invalid. It is certainly possible to test whether or not division by zero results in an (invalid) arithmetic exception.
Does it mean that the code should continue even if an divide by zero exception is throw, and should provide correct return code based on the instruction after the divide by zero.
So to test it, just rewirte register R2 to an value desired and check if the return code is tha least 8 bit in R2 rather than 136 (return code caused by Floating point exception).
"If an divide by zero exception is throw[n]" -- Per the above, and #16, this cannot happen for DIV.
When compile the code "div $14,$3", where $3 is set to 0, the mips-compiler will generaete break instruction (as shown below), which is not in the spec. In this case, should it return -12 for Invalid instruction?
1000000c: 01c3001a div zero,t6,v1
10000010: 0007000d break 0x7
Ah, this is problematic. The compiler shouldn't be generating these due to the use of -mno-check-zero-division (per https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/MIPS-Options.html), but it seems to be doing so anyway. A solution to this is to simply treat the break instructions (R-type, function code 13) as nops, however this isn't currently part of the spec and I don't think it's fair to add it this close to the deadline. I will try to come up with an appropriate solution but, if I cannot, I will ensure not to test for this case.
To provide a more concrete answer on this: I will not test behaviour that relies on implementation of instructions that are not part of the spec (in particular BREAK), however I may test for correct implementation of DIV with rt = 0 since the latter is defined by the ISA.
This thread highlights an important point: don't trust the tools!