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

[Amadeusz Sławiński]

Resending because it got stuck in moderation queue due to size
logs in separate mails

Here are results of my testing booting OS X on latest trunk
Logs in attachment

Not patched ones (fails without get-key-map):
10.0.log
10.2.log
10.4.log

Patched with gsoc get-key-map patch:
10.0-gkm.log
10.2-gkm-panic.log
10.4-gkm.log

Patched with gsoc divide by 0:
10.2-gkm-dvb0.log

Logs from patched boot without CIF:
all-without-cif.log


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


Question is how to implement it, or maybe just use gsoc patch?


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


Another problem is that it seems to be unable to open/load kernel.


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

Amadeusz

[Amadeusz Sławiński]

Logs from 10.0

[Amadeusz Sławiński]

Logs from 10.2

[Amadeusz Sławiński]

Logs from 10.4 and all-without-cif.log

[Mark Cave-Ayland]

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.

[Programmingkid]

On Dec 21, 2012, at 6:27 AM, Mark Cave-Ayland wrote:

 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?
What if someone made their program knowing that division by zero is equal to zero? This is
the behavior that Apple's Open Firmware follows. I think we should follow it for the
PowerPC target.

[Tarl Neustaedter]

On 2012-Dec-22 23:38 , Programmingkid wrote:
> >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?
 What if someone made their program knowing that division by zero is equal to zero? This
is the behavior that Apple's Open Firmware follows. I think we should follow it for
the PowerPC target.
That would be incorrect, by all standards. Indeed, Solaris uses divide 
by zero as a fatal error indicator during the boot process, knowing it 
will trap.

[Programmingkid]

On Dec 22, 2012, at 11:46 PM, Tarl Neustaedter wrote:

 On 2012-Dec-22 23:38 , Programmingkid wrote:
>> >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?
> What if someone made their program knowing that division by zero is equal to zero?
This is the behavior that Apple's Open Firmware follows. I think we should follow it
for the PowerPC target.
 
 That would be incorrect, by all standards. Indeed, Solaris uses divide by zero as a fatal
error indicator during the boot process, knowing it will trap.
But this isn't Solaris we are working with, this is Apple software. Division by zero
equals zero.

[Tarl Neustaedter]

On 2012-Dec-22 23:53 , Programmingkid wrote:
 Division by zero equals zero.
That is incorrect. By definition, division by zero cannot return a 
meaningful answer.

http://en.wikipedia.org/wiki/Division_by_zero

[...]
 In computer programming, an attempt to divide a floating point number

 by zero will by default lead to positive or negative infinity by the 
 IEEE 754 floating point standard. However, depending on the 
 programming environment and the type of number (e.g. integer) being 
 divided by zero, it may: generate an exception, generate an error 
 message, cause the program to terminate, generate either positive or 
 negative infinity, or result in a special not-a-number value.
There are two mathematical theorems in conflict when dividing zero by zero;

  * Dividing by zero cannot return a meaningful number, since for all
    a/b = x there must be a corresponding x*b = a. If b is zero, there
    is no value of x which can produce a meaningful a.
  * Dividing anything by itself (in this case, 0/0) /shall/ produce the
    identity, which for real numbers is 1 (it's something else for
    matrices). Specifically a/a = 1, thus 1*a = a.

The answer is that as far as mathematics (and standards like IEEE 754) 
are concerned, dividing 0 by 0 is either a trap or a NaN. Not zero. if 
Apple hardware is producing zero as a result of dividing zero by zero, 
I'd consider that buggy hardware.

I do note from a Google search that at least the PowerPC 8360 does the 
correct thing with divide by zero, which breaks someone's application 
that depended on different behaviour:

http://stackoverflow.com/questions/6460558/powerpc-how-to-make-div-0-retu...

I do find amusing the comment about the original dependency on 1/0 
producing 0:

 I've inherited legacy code like this before & I feel your
pain. You 
 want to shake your fist at the people who installed such bone-headed 
 behavior, but right now shaking your fist doesn't help you ship 
 product. You need a solution. Good luck.

[Mark Cave-Ayland]

On 23/12/12 04:53, Programmingkid wrote:

> That would be incorrect, by all standards. Indeed, Solaris uses
divide by zero as a fatal error indicator during the boot process, knowing it will trap.

 But this isn't Solaris we are working with, this is Apple software. Division by zero
equals zero.
As Tarl points out, division by zero is really undefined. Hence we need 
to make this behaviour customisable on a per-architecture basis so that 
we can provide the workaround just for PPC.


ATB,

Mark.

[Programmingkid]

On Dec 24, 2012, at 6:29 AM, Mark Cave-Ayland wrote:

 On 23/12/12 04:53, Programmingkid wrote:
 
>> That would be incorrect, by all standards. Indeed, Solaris uses divide by zero as
a fatal error indicator during the boot process, knowing it will trap.
> 
> But this isn't Solaris we are working with, this is Apple software. Division by
zero equals zero.
 
 As Tarl points out, division by zero is really undefined. Hence we need to make this
behaviour customisable on a per-architecture basis so that we can provide the workaround
just for PPC.
We could add an if condition to the mudivmod() function so that it returns zero if the
denominator is zero and the architecture is PowerPC.

[Mark Cave-Ayland]

On 23/12/12 04:46, Tarl Neustaedter wrote:

 That would be incorrect, by all standards. Indeed, Solaris uses
divide
 by zero as a fatal error indicator during the boot process, knowing it
 will trap.
Hi Tarl,

Incidentally when this discussion came up before, I remember there was 
some discussion on how this was handled in Sun's implementation, but I 
can't remember what the outcome was.

What is the result of typing "2 0 /" into the OpenBoot Forth 
interpreter? Does it call invoke a low level trap handler, throw a Forth 
exception, or is the zero denominator detected in some other fashion?


ATB,

Mark.

[Tarl Neustaedter]

On 2012-Dec-24 07:49 , Mark Cave-Ayland wrote:
 What is the result of typing "2 0 /" into the OpenBoot Forth 
 interpreter? Does it call invoke a low level trap handler, throw a 
 Forth exception, or is the zero denominator detected in some other 
 fashion?
{0} ok 2 0 /
ERROR: Last trap: Division by Zero

{0} ok