I was developing Open Boot - the Forth-based firmware that eventually became Open Firmware AKA the IEEE 1275-1994 Standard - at Sun back in the late '80s. It w

I was developing Open Boot - the Forth-based firmware that eventually became Open Firmware AKA the IEEE 1275-1994 Standard - at Sun back in the late '80s. It was intended to replace Sun's existing "sunmon" firmware which was written in C. The diagnostics group that maintained sunmon was adamantly opposed to Open Boot, probably mainly because it threated their ownership of the firmware. The argued against Open Boot, thinking that they had an ironclad argument: "Forth is interpreted therefore it is too slow". The argument totally backfired because I knew some facts about the hardware that had apparently escaped them. The dominant factor in the perceived firmware speed was scrolling text on the non-accelerated megapixel frame buffer. That involved a megapixel memory-to-memory copy for every line. On the monochrome display it was terrible and on the color frame buffer it was horrendous. The sunmon firmware ran from EPROM, whose access time was glacial compared to RAM and even worse compared to cache - and EPROM was not cacheable. To make matters even worse, on the SPARCstation 1 that was the first target for Open Boot, the EPROM data width was only 8 bits, so a 32-bit instruction fetch took 4 super slow EPROM accesses. You see where I am going with this, right? All it took to leave sunmon in the dust was to copy the screen-scrolling and bitblt routines into RAM. Just to pour salt on the wound, I also copied the modest-sized set of code words at the core of Forth into RAM. Direct-threaded Forth ran from RAM substantially faster than compiled C code ran from EPROM. Our project manager did not let me turn on the cache on the first shipment, worrying about bugs, but relented on later revisions. After the cache was turned on, Forth just flew. The fact that Forth is so well-factored, and the actual machine code is confined to a small compact area, meant that the cache performed extremely well. Furthermore, since Forth didn't need to use the SPARC register windowing mechanism - register windows were designed for C-style stack frames and are essentially useless for Forth stacks - the endemic SPARC problem of window spill and fill handlers didn't affect the firmware at all. That made the firmware much more adept at post-mortem examination of kernel crashes. In a lot of system code, the performance can be dominated by access to devices that are much slower than cache. In that environment, so long as you are careful about a few CPU intensive routines like memcpy and bitblt, threaded code can be nearly as fast as compiled code, and sometimes faster. And it is much more compact, which matters a lot when you have to fit everything into some flavor of ROM.