What PowerPC systems trap on divide by zero?
PPC 8360
http://stackoverflow.com/questions/6460558/powerpc-how-to-make- div-0-return-zero-as-a-result
The 8360 is an e300 core, which implements the PowerPC architecture just fine, which means it will not generate an exception for any integer divide (or other integer insn) ever. The result of the divide instruction is not zero, but instead undefined (by the architecture; specific implementations have their own behaviour, of course).
The question you linked is about *floating point* division by zero. Those can be set up to generate an FP exception (not a trap exception!); if you want to be able to handle such exceptions, fudging things so it seems the instruction returned some specific value (as in the question) you will have to switch FP exceptions to be exact, which is very expensive performance-wise.
Anyway, divide by zero in Open Firmware. There are three things we want: a) Compliance to the standard; b) Traps if running on Sun hardware, since OBP does too; c) No traps if running on PowerPC hardware, since no existing system does, and Apple's bootloader depends on this behaviour.
So, how to implement this. Firstly, we should have the same behaviour for *all* divide insns (/ u/ mod umod /mod u/mod um/mod mu/mod sm/rem fm/mod and whatever I forgot), not just um/mod and those words derived from it. Secondly, we get what we want if we just use the machine's (or C's) divide operator. So it seems the actual problem (if there is one at all) is that OpenBIOS' mu/mod does not behave as the hardware would. Related, / and the other single-precision division words do not need to call mu/mod (which is very expensive), they can much cheaper be implemented as C words (cheaper in execution time that is -- it costs more code :-) )
Segher