Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uwm.edu!linac!att!ucbvax!PUCC.PRINCETON.EDU!EBERBERS%yubgef51 From: EBERBERS%yubgef51@PUCC.PRINCETON.EDU (____ Zarko Berberski ____) Newsgroups: comp.lang.forth Subject: Re: RFC -- Writing an operating system using Forth. Message-ID: <9104191311.AA15851@ucbvax.Berkeley.EDU> Date: 19 Apr 91 06:19:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: ____ Zarko Berberski ____ Organization: The Internet Lines: 72 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*