mimperat@watcgl.waterloo.edu (Marco Imperatore) (04/18/91)
Greetings. 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 very limited experience with Forth but I have LOTS with C. The little I know of Forth leads me to believe that it would be a lot harder to write an OS using Forth and that the resulting product would not be as efficient or portable. Can anyone convice me otherwise? If possible, please provide extremely simple code examples in your explanation. The reason I am asking these questions is because I am in the process of designing a Unix-like distributed OS for 386-based machines and I am investigating likely possibilities for OS implementation languages. I will keep reading this newgroup for any followup articles. If you wish to reply directly to me, please use the address in my 'signature' below. Thanks. -- Marco Imperatore Computer Graphics Lab, University of Waterloo, Waterloo, Ontario, Canada mimperatore@watcgl.waterloo.edu
Mitch.Bradley@Eng.Sun.COM (04/18/91)
> 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
EBERBERS%yubgef51@PUCC.PRINCETON.EDU (____ Zarko Berberski ____) (04/19/91)
In the old 8-bit days many FORTH implementations were the
operating systems with complete perihpherals control and even the
multitasking. Most present 16/32-bit FORTH implementations tend to
rely on "parent" OS for disk and console I/O and that might lead you
to the idea of FORTH not being able to serve as a language for an
operating system. The reality is somewhat oposite - if you are to
produce the new OS (i.e. not to port already written OS) then you
might need quite special C compiler in order to solve several
problems (ROM-ability, booting new machine, loading and
executing programs are just some of them ) or you will have to
use assembler for some substantional amount of code. Not to
mention the C-compiler bootstraping. With FORTH, you can take a
quite inexpencive (even PD) FORTH capable of recompiling itself
producing relocable or position-indepedent or position alligned
code. So as the first step you would simply remove OS-specific
words, rerwrite just a several words (to adapt console I/O and
RS-232 communucation for the new hardware), produce ROM-able
image, burn it in EPROM and - voila - the first version of your
new system is born. Now you can write/debug disk I/O, improve
console I/O, install various interrupt handlers and multitasker
in quite early stage of new OS design. So, the first advantage
is that your OS will be able to grow with the speed you need -
you woun't be forced to write some substantial amount of code
before you even have a chance to see how this system is working
(if it is at all). Second, you have spent minimal effort on
things that are no particulary interesting an that gives you more
time (and nerves) to spend contemplating and implementing more
interesting parts of your new OS. Third, you have saved yourself
some K bucks (C-based cross-development systems are everything
but cheap). Anytime when you'd like to port your FORTH-based OS
to some other machine you'll have to change substantially less
code then in the case of C-based OS, not to mention that you'll
need very little machine-code-level changes.
Now about the efficiency. If you think that standard C
compilers produce some specially efficient code - just start
some machine debugger and take a look - you'll be surpised.
You are not using HP compiler with 3-level optimizaion - right?
Forth code is usually compiled as a threaded but you can quite
easily convert it to subroutine threaded and even pure machine
code (or you can purchase some professional FORTH sytem to do
that for you - still at the fraction of cost of even the worst
C-based cross-development system). In most cases you actually
woun't need anything more then subroutine threaded code and it
makes debugging much more comfortable. The space efficiency is a
matter of tradeoff - you can use threaded code and have very
small executable code, subroutine threaded and have somewhat
longer but still substantially smaller code (comapred to usual C
compiled code) and finaly you can use so called native code
(most FORTH words "expanded" into a sequence of machine code
istructions instead of subroutine calls or just addresses) and
have quite large executable code but still smaller than usual
product of C-compiler. This is usually different if you are just
producing an isolated program on some other OS since then you
must include most of FORTH kernel in order to make a stand-alone
application. But if you are producing new OS then you already
have that 16-128 K FORTH kernel in yor machine and all
executable code uses it.
I suppose that you intend to produce experimental OS, not
something that you would immediately try to sell. Otherwise you
might have to 'force' your emnploees to learn FORTH. In that case
you should thain them in a try-and-see manner since that is
definitely the easyest and the fastest vay to leran FORTH. Once, I
gave a friend of mine "Starting Forth" and after a 7 days he was
able not only to read/write in FORTH but even to understand
explanations of FORTH internals - and he wasn't programmer.
*CANCEL*