OFW vs. proprietary BIOS

[Mitch Bradley]

Edward Cherlin wrote.
> I also want to see Open Firmware replace proprietary BIOSes everywhere. 

I'd like that too, but it won't happen.  The market forces that drive 
the computer business still favor proprietary thinking, notwithstanding 
the many FOSS arguments to the contrary.  Intel calls the shots by 
controlling a big percentage of the silicon designs, and Intel is 
pushing UEFI, partially because it allows them to keep their 
chipset-dependent startup code proprietary.  The board manufacturers do 
what the dominant silicon vendor allows them to do.

> In fact, I would like to see OFW-only embedded systems,
> since FORTH is designed for that environment.

I have built such devices, including a web-interface multi-headed 
high-speed camera that could capture the dynamics of golf club to ball 
impact.  The product shipped for awhile, then the company tanked in the 
dot-com bust.

A lot of the OFW functionality is targeted toward the task of managing a 
large collection of possibly-plug-in I/O devices, then booting a general 
purpose OS.  That isn't necessarily useful for your random embedded 
system.  For embedded applications that don't need that level of 
OFW-ness, I have a small Forth interpreter that provides the same Forth 
interactive development/execution/debug environment as OFW, omitting all 
the device tree and booting elaborations.  It fits easily on an ARM SOC 
such as the Atmel AT91-SAM7 family, leaving plenty of space for 
application code and data.  Guess how the OLPC multi-battery-charger is 
programmed?

> (I am assuming that Mitch can add real-time capabilities to OFW,

It already has them.  The golf camera could time the arrival of a golf 
club to the ball with microsecond resolution.

You can add round-robin multitasking (essentially multithreading) to OFW 
by loading a file.  The core data is all in what is essentially 
thread-local storage.  OFW doesn't have preemptive multitasking, but 
I've never really needed it.  Many real-time problems can be handled 
rather well with a combination of explicit-yield tasking and judicious 
use of interrupt routines.  The added benefit of avoiding preemption is 
that synchronization is much easier.

>  and that a variety of
> development environments are available for such systems.) Or perhaps
> OFW/Parrot hybrids. I don't know. It's Free Software, folks, what do
> you want to implement today?
>   

The usual Free Software answer to that question is "I want to implement 
yet another version of something for which there already exists a dozen 
other implementations".   Which is exactly the problem.