On 03/05/14 10:56, BALATON Zoltan wrote:
On Fri, 3 May 2014, Tarl Neustaedter wrote:
I'm not volunteering to do the work (lest I hear my boss scream in agony), but I suspect this is a case that it just drops in and works. Lillian wrote it for the OneLaptop project, and I understand that implementation and OpenBios haven't diverged all that much.
Problem is I don't know where to drop it to try if it works and if it doesn't I don't know how to debug Forth so I could only shoot in the dark. I don't even know where to start with this Forth driver.
Sadly the PCI code in OpenBIOS is still written in C so there would be some interface work required there.
In terms of testing the code, Forth is an interpreted language so you can literally copy/paste from the source files into a serial console and see what happens ;) I suspect that the reality will be slightly different though, for example we know that OpenFirmware has behaviours which aren't implemented in OpenBIOS.
I should also point out that given that the original OpenFirmware was written almost completely in Forth, a lot of the semantics are so tightly tied in that it would make sense to start looking at bits of Forth as you come across them, and even better you can use the Forth debugger (see README.debugger) to step through words one at a time.
From the time I've spent working on OpenBIOS, I would say that the 2 things that have cost me the most time have been excessive use of C and premature forking of individual architectures. Historically OpenBIOS has a lot of C drivers borrowed from other projects which is great for getting something going but causes more headaches further down the line. Maybe the original aim was to convert the C drivers over to Forth as time allows? I don't know as that was prior to my involvement in the project.
As an example, last summer I ended up rewriting the majority of the display layer and I would say that most of the bugs were caused by C structs and Forth structs not being in sync, plus there was massive code duplication between C and Forth. Currently the C code uses pointers into the Forth dictionary where required so that the values are always consistent, and now C is only used for low-level primitives e.g. blitting that can be used across all architectures.
Similarly I spent time creating the common libopenbios since there was a lot of code duplicated between PPC, SPARC32 and SPARC64 which required multiple fixes and testing for minor fixes. But to go back to my original point: the more cross architecture work we do, the less maintenance is required and all architectures get bugfixes for free. And if we need cross architecture, then Forth is a better choice since it provides the greatest compatibility with clients and the IEEE1275 specification, and you get to debug and develop live systems step-by-step without having to rebuild/redeploy.
ATB,
Mark.