In the SIC/XE architecture, what happens after execution of DIV #0 and DIVF #0 instructions? How do other architectures deal with divide by zero situation?
Asked
Active
Viewed 69 times
0
-
Did you check the instruction set reference? What did it say? – fuz Mar 16 '21 at 18:14
-
1Being a made-up machine for teaching purposes, it's not clear that it actually has a complete instruction set reference. I only found things like https://cs.iupui.edu/~xzou/teaching/csci30000/Figures/Page495-499-Appendix-A.pdf which list the instructions but don't explain their behavior in detail. You might have to just consider it "undefined", or test or read the source of various simulators to see what they do. – Nate Eldredge Mar 16 '21 at 18:26
-
2Some architectures trap or fault, depending on your terminology. Others, like RISC V, just give a pre-defined result. – Erik Eidt Mar 16 '21 at 19:16
-
@fuz Ya, i did. It didn't have any information regarding what happens when divide by zero happens. – Sai Aravind Mar 17 '21 at 02:24
-
@NateEldredge From what i saw in a few simulators. These where the typical handling of divide by zero - Move on to the next instruction without affecting the accumulator. - A divide by zero exception is generated and the simulator stops. – Sai Aravind Mar 17 '21 at 02:26
-
Other architectures: [Why does integer division by -1 (negative one) result in FPE?](https://stackoverflow.com/a/46380011) compares ARM vs. x86 (for the related case of `INT_MAX / -1` signed division overflow, which is the same on x86 as integer division by 0). And why under Linux that HW exception gets the OS to deliver a SIGFPE arithmetic exception signal to the offending user-space process. – Peter Cordes Mar 17 '21 at 03:17
-
*Floating-point* division by zero on most architectures just gives you a NaN, with the default FP environment where FP exceptions are masked. But you can unmask some/all FP exceptions so they actually trap, instead of just recording the occurrence with a sticky flag. – Peter Cordes Mar 17 '21 at 03:19