[OpenBIOS] [RFC 3/3] SPARC32/64: Mimic Sun's OBP behaviour if a divide by zero occurs.

Segher Boessenkool segher at kernel.crashing.org
Fri Jan 11 19:22:16 CET 2013


>> 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




More information about the OpenBIOS mailing list