testing Max OS X boot on latest trunk (revision 1080)
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
Logs from 10.0
Logs from 10.2
Logs from 10.4 and all-without-cif.log
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.
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.
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.
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.
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-return-... 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.
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.
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.
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.
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
participants (4)
-
Amadeusz Sławiński -
Mark Cave-Ayland -
Programmingkid -
Tarl Neustaedter