Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!Eng.Sun.COM!Mitch.Bradley
From: Mitch.Bradley@Eng.Sun.COM
Newsgroups: comp.lang.forth
Subject: Re: RFC -- Writing an operating system using Forth.
Message-ID: <9104180132.AA01029@mitch.Eng.Sun.COM>
Date: 18 Apr 91 01:32:22 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 88


> I would be interested in finding out if anyone has thought about writing
> an operating system in Forth, or if such systems has already been created.
> Furthermore, I was wondering if anyone could give me a hypothesis (or relate
> an experience) as to whether C is preferable to Forth for such a purpose.

I have written operating systems in both C and Forth, and I prefer Forth.
I can debug Forth code about 10 times faster than I can debug C code,
especially when trying to debug OS-implementation-level code.

Also, Forth gives you a lot more flexibility in terms of layering; C tends
to get stuck at a particular level of abstraction.

I know of several projects that were started in C, got bogged down late
in the game (with the schedule in severe jeopardy), switched to Forth in
desperation, and finished with ease.  It's hard to believe until you have
experienced it, but the amount of Forth code that can be cranked out in
a short time can be astonishing.


> The little I know of Forth leads me to believe that it would be a lot
harder to write an OS using Forth

I have found just the opposite (and I was a C programmer for several years
before I discovered Forth).  A lot of things that are dull, boring,
time-consuming chores in C turn out to be a snap in Forth.


> and that the resulting product would not be as efficient or portable.

Probably true in practice "on average"; not true in theory.

Time Efficiency:

Inherently, Forth can be as fast as C, because Forth can be compiled directly
to optimized machine code, just like C.  In practice, most Forth
implementations compile to threaded code, which is somewhat less efficient
han machine code.  However, Forth "native code compilers" are available for
80x86, 680x0, VAX, and probably numerous other machines.

Personally, I prefer threaded code anyway, because it is easier to debug.
In my experience, system performance is nearly always dominated by a
small number of bottlenecks.  I find that Forth's easy interaction makes
it easy to locate those bottlenecks, and once located, a few lines of
assembly code will get you quickly to near-theoretical-maximum performance.

Space Efficiency:

In some applications, I have found that Forth can be up to twice as space-
efficient as C.  This is largely due to the ease with which the Forth
kernel implementation can be tuned.  With C, it is a major effort to
change any aspect of the code generation or the machine run-time model.

Program Portability:

As things currently stand, C definitely has the edge here.  When ANS Forth
comes out and implementations of it abound, Forth and C will be about even
in this respect.  Until then, C is the clear winner.  Even now, it is possible
to write very-portable Forth code, but it is somewhat tricky and the
techniques for doing so aren't widely known.

All this assumes that one is interested in purchasing "off the shelf"
Forth implementations from multiple vendors.  On the other hand, if
one sticks to a particular Forth implementation model, and ports the
same entire Forth system to different platforms (which is remarkably
easy to do with some Forth models), then Forth code can be extremely
portable.

Programmer Portability:

C programmers are a dime a dozen, and Forth programmers are comparatively
rare, so programs written in C generally have a much wider human audience
that Forth programs.  This fact is not likely to change much; if anything,
the scales will probably tip more toward C as time goes on.

This can be a significant factor if you intend for your system to have
a long-term lifetime and for other people to take it over from you and
maintain it.  If your system is a research project/exploration/prototype,
then this is probably not an issue.  I don't mean to say that Forth
programs can't be maintained in the long term by teams of programmers;
on the contrary, I am the leader of a team of Forth programmer that is
maintaining a substantial Forth-based application (the Sun Workstation
firmware) over many different platforms.  The point is that you have to
do a little searching to find Forth programmers, whereas finding C
programmers is a no-brainer.


Mitch Bradley, wmb@Eng.Sun.COM