CamelForth

Sometimes, your words come back to haunt you. This is not one of those times. The Forth Interest Group UK links to a newsgroup reply I wrote back in 1996, describing the advantages of Forth. I'm glad that the Institut für Computersprachen preserved those words before I thought to; I'd like to preserve them now, on my own web site, because fourteen years later, they still express what I think.

From: Brad Rodriguez
Newsgroups: comp.lang.forth
Subject: Re: Hang on, isn't Forth out of date now?
Date: Sat, 10 Aug 1996 04:39:02 -0700

Andy, thanks for the provocative question. It's helped me compose my thoughts for a flyer I'm writing.

No, Forth isn't out of date. Forth is still great because of the following benefits:
1. It is simple to build from the bottom up.
2. You can get an _application_ to run in a miniscule amount of RAM.
3. You can try things out in real time as you build your system.
4. Compared to any other interpreted language, it is fast.

Allow me to elaborate:

1. Forth remains one of the few environments which is totally comprehensible by one person. This is a big plus when you're working in safety-critical systems, or whenever you need to verify program correctness.

2. Forth does indeed make "the best out of a slow microprocessor with little RAM." Such processors are more common than PCs -- they're called embedded systems. It will be a long time before your car's fuel-injection system has 16 MB and a 1.25 GB hard disk. (And most embedded processors are NOT supported by Borland C++.)

3. There is simply NO substitute for an interactive interpreter when debugging. Even an edit-compile-test cycle of 5 seconds feels clumsy, after you're used to testing any subroutine by typing its name. Can your debugger let you manually try different input parameters? (My Borland compiler can't.) And you should try a modern interactive Forth to learn how easy it makes testing embedded hardware! I've yet to meet the in-circuit emulator that lets me exercise I/O as easily as a few simple lines of Forth code. (Or lets me test multiprocessors or distributed systems at all!)

4. Forth is still fast. Modern compilers produce code as good as any other language -- not all Forths use threaded code! (I could relate a horror story I heard about an engine control system written in C++.) Forth is certainly the fastest interpretive language around; and besides the debugging advantage, I've found interpretive Forth to be superior for incremental development.

However, I have other reasons for using Forth:

5. Forth is _extensible_. This means that if the language does not support some feature or capability you need, you can add it...not as a subroutine package, but as part of the language itself. Can you imagine writing object-oriented code, if every reference to an object had to be through a function call? That's how I feel about other languages' implementations of multitasking, multiprocessing, and networking. Only in Forth can these be truly transparent.

6. Forth lets me work at a high level of _abstraction_. Between language extension and "active" data structures, when I write a Forth application, I am really writing in the language of the application -- not the language of the compiler. This makes the program easier for a newcomer to read, and easier to maintain.

Like most programmers, my choice of language is based on personal preference. I find that I think more clearly in Forth, and from past experience I estimate I'm 5 to 10 times more productive in Forth than in C. Others may not share this preference or facility. Forth may not be your preference, but it's certainly "relevant" -- now more than ever.

Brad Rodriguez

This web site will be down tonight for a server upgrade. Starting at midnight Eastern Time, lasting for a few hours.

Robert Edwards has advised me of the availability of a Z8 Forth:

CamelForth version 1.4 for the 8052 and Silicon Labs (formerly Cyngal) C8051F is now available for download. This is a customized version of CamelForth/8051 which runs entirely within the 256-byte RAM space of the 8052 -- including the text interpreter.

This can be optionally assembled to run on the Silicon Labs (Cygnal) C8051F, again using 256 bytes of on-chip RAM. On this processor, new definitions can be compiled directly to the on-chip Flash ROM. After an application is compiled, the RAM contents can be saved to Flash ROM to be automatically loaded on reset. Also, a user-defined word can be automatically run on reset.

Also included are experimental source code for TO-variables, Special Function Register access, and adding machine code definitions. Note that, because of the limited RAM, this does not include the 8051 multitasker.

Harold Rabbie has contributed a CamelForth port for the RCA 1802 "COSMAC" microprocessor. This is available for download from this site, as is the MS-DOS 1802 cross-assembler that you will need to compile the code.

CamelForth/1802 runs on an 1802 simulator. C language source code for that simulator is included in the download, and can be compiled for Windows (using Cygwin) or Linux. The simulator includes the ability to trace execution at either the machine code or Forth level. It should be straightforward to modify the serial I/O drivers and memory map to run on any 1802 hardware that supports an RS-232 terminal.

Questions can be addressed to the author on the forum.

I've decided to start fleshing out the "links" section of the CamelForth site, with links to more Forth resources. I've begun with the Forth Interest Group and the Forth Interest Group UK. I'll probably add links in pairs, every few days, since the latest two links are featured in the right column.

CamelForth version 0.2 for the Texas Instruments MSP430 is now available for download. This is the first release, and should be considered "Alpha Test" code at the present time.

CamelForth/430 is currently compiled for the New Micros Tini430 board (MSP430F1611 chip), but it should be usable on any MSP430 family processor with at least 512 bytes of RAM, 8K of Flash ROM, and a USART for serial I/O. You will need the free IAR Embedded Workbench Kickstart to compile CamelForth/430.

This implementation of CamelForth features direct-to-flash compilation, which means that your Forth programs can be downloaded and compiled directly into the 40K of available Flash memory on the MSP430F1611, and 9.5K of RAM is available for your application data. (8K of Flash, and 0.5K of RAM, is used by the CamelForth kernel.) For more information about the use of Flash ROM, see the included "readme" file.

I received an email from David F., the author of muFORTH. muFORTH is an x86 Forth for Linux systems, but David is working on porting muFORTH to several embedded CPUs -- the ARM, AVR, and Freescale HCS08 have been mentioned.

Judging from his blog I think the HCS08 is the first priority. (We met when I posted, on the Freescale forum, a question about downloading to 'S08 parts. No, I'm not doing an 'S08 Forth at this time...my query was for an unrelated project.)

Some friends sent me this bit of news. If you've been wondering what Chuck Moore, the inventor of the Forth language, is doing these days, he's still working on Forth chips. He's now Chief Technology Officer at IntellaSys, whose new product is the SEAForth 40C18, a 40-processor array of Forth engines ("25 billion operations per second").

Obviously, I won't be porting CamelForth to this chip -- it already has a Forth implementation. Someday, when my free time becomes more copious, and I've caught up with other projects, I wouldn't mind playing with one of these.

We do seem to attract hardware developers! I received a request from another data sheet search engine, datasheetdir.com, for a link and a mention on this page. I'm happy to oblige. I know how difficult it is to find data sheets for some parts.

Their web site seems to be most easily used as a search engine for a specific part number. You can also browse by parts category, but there are so many chips made for almost every function that you'll be overloaded by the selection.