CamelForth

Back at last! Last week we -- and other sites running the e107 CMS -- got hammered by a particularly nasty Distributed Denial of Service attack. This was an attempt to exploit a vulnerability in an older version of e107. We're protected against that exploit, but the sheer volume of requests -- literally millions, coming from thousands of IP addresses -- was enough to bring our server down. We've been working with our web host for the last several days to harden the site still further, and increase our server resources to handle the load.

The attacks continue, and you may occasionally get timeouts when visiting the site. But we seem to be on top of the situation now. Thanks for your patience.

Update: The user login and signup forms should be working now.
Update 2: (22 Jul) The contact form is working now. Sorry about the oversight.

I am fortunate to own a copy of William H. Payne's Embedded Controller FORTH for the 8051 Family (Academic Press, 1990). I recently received an email from Mr. Payne, informing me that the source code and documentation* for this Forth is now available for free download at his website.

* "Documentation" refers to readme files and installation instructions, not the book itself. You can still buy the book new from Amazon or used through AbeBooks.

User 'peter' has contributed a "first pass at a Linux port" of CamelForth/8086. He's also expanded it to a 32-bit model. It's still written in x86 assembler, so it isn't portable to other Linux systems. The "alpha test" version is now available in the Downloads area.

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.