On 21/12/12 11:01, Amadeusz Sławiński wrote:
10.2 ones show that there is need for some solution regarding division by 0, some notes from my talks with Mark:
My g5 machine returns 0 when dividing by 0, no warnings are printed: 0> 0 0 / ok 1> . ok 0> 0
0> 2 0 / ok 1> . ok 0> 0
For some more context, the reason we need to allow divide by zero for OpenBIOS PPC is because of this amazing piece of brain-dead programming in BootX's DrawSplashScreen() function:
if (gBootFileType != kNetworkDeviceType) { SpinInit(0, 0, NULL, 0, 0, 0, 0, 0); }
where SpinInit() invokes the Forth slw_spin_init word via CIF that looks like this:
: slw_spin_init dup FFFF and to cursorH 10 >> drop dup FFFF and to cursorW 10 >> to cursorPixelSize dup FFFF and to cursorY 10 >> d# 1000 swap / to cursorDelay dup FFFF and to cursorX 10 >> to cursorFrames to cursorAddr to screenIH ['] slw_spin to spin ;
It's fairly easy to see that if you invoke slw_spin_init with all its parameters set to zero, you'll get a divide by zero error.
Question is how to implement it, or maybe just use gsoc patch?
For reference, the GSOC patch is this: http://lists.openbios.org/pipermail/openbios/2011-August/006651.html. I'm not sure this is the best way to do it though.
I'm currently thinking the best way would be to alter the "/" Forth word using throw/catch and have it throw an exception with a zero denominator which calls a "divide-by-zero" defer word. This behaviour can then be specified on a per-architecture basis.
I also like still allowing internal C divisions to invoke the processor divide by zero traps, as it's very useful at pointing out when you've forgotten to set something rather than carrying on with an erroneus result. Do people think this is an acceptable solution?
Also it seems that Mac OS X seems to provide it's own fill-rectangle and +draw-rectangle it prints: FILL-RECTANGLE isn't unique. and also similar message when I apply gsoc draw-rectangle patch so it seems that this one isn't needed
Yes, that's correct. BootX deliberately overrides the existing routines with its own. Perhaps OpenBIOS is a little bit verbose in declaring this, but I don't see this is an issue.
Another problem is that it seems to be unable to open/load kernel.
I do see messages about opening "mach_kernel" but as yet I haven't managed to spend time debugging how/why this is failing.
On graphic side of things it seems to draw things better than with gsoc patches, graphics are not weirdly resized, but there is not much to see except boot folder graphic (10.0)/white apple(10.2, 10.4).
Indeed. The OpenDarwin image looks quite respectable here :)
ATB,
Mark.