[OpenBIOS] testing Max OS X boot on latest trunk (revision 1080)

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Fri Dec 21 12:27:44 CET 2012


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.



More information about the OpenBIOS mailing list