ANSI Forth is ANTI Forth
Another politically incorrect essay

For years I was a strong advocate for the ANSIfication of Forth. Unlike Chuck Moore who just does Forth I had a background from Fox Consulting with clients like Bank of America and Pacific Bell for many years. I mean things couldn't exist without all these standards and people like me love them.

Long before Chuck started laying out my F21 microprocessor my involvement was simulating the chips in development and reporting the results to Chuck and the public. My chip was called the Foxware F20 at the time. I implemented a whole set of different Forth compilers on top of the simulators and published the results. I got tired of the jokes about not having real machines and having to use simulators but I found the research very educational. I published the results of idtc, dtc, stc, ANS and minimal, and optimizing native code compilation with register allocation, inlining, and other cool stuff like parallelization. I guess I could publish more of those ancient documents on the web.

When the iTV Corporation was formed Chuck got together with a couple of guys from NASA and began the mission of making really cheap internet appliances with the technology. They signed a codevelopment deal with Ultra Technology to license an F21 spinoff for their use and they hired me as the first employee.

They hired more ANSI Forth programmers and promoted me from "Cool Software Developer" to "Programming Manager."

One day Chuck printed out a page on his printer:

Jeff Fox
 Forth

and came by and put it up on my cube and said,
"I decided to put this up because I decided that that is what you do."

In his first public talk about his Color Forth Chuck Moore said a couple of things about Forth and in particular ANSI Forth and I know exactly what he was talking about. I have been reluctant to speak out about it because what I will say is so politically incorrect. I don't have the time to write a book about it right now, but I will write a short web page about why I now say that ANSI Forth is ANTI Forth.

Chuck said,
"I had reservations about ANSI. I worried that it would be a disaster and not merely a dubious advantage. All of my fears of the standard and none of the advantages of the standard have come to pass. Any spirit of innovation has been thoroughly quelched. Underground Forths are still needed. I said I thought the standard should be a publication standard but they wanted an execution standard. ...

There is a problem that I first saw at iTV. It was the first time I have been in the presence of a Forth project that I wasn't contributing to. I saw how other programmers use Forth. They don't always get it right.

Besides stacks plus colon definitions there is something else. There needs to be another book written about writing good code."

Neither of us has the time right now to write such a book but I will write this short page with my opinion on the subject of ANSI Forth. I have changed sides once in this debate and would be happy to be convinced that I am wrong about this now.

The dubious advantage that Chuck was refering to is related to two illusions. One is that ANSIfication is good because it finally gives Forth credibility in the comp sci and business community. The other is the dangerous illusion of portability in ANSI Forth.

Forth is the simplest language. It is simpler than Logo and it should be taught to children after counting and before long addition. That is the real power of Forth, it is so small and sharp that it can cut up most any problem into well factored testable components.

Forth implementations are usually interactive and offer access to the internals of the compiler and interpreter and everything and make it easy to change anything. Learning to play with those little DUPs and OVERs is like playing with wooden blocks, stacking them and seeing what happens.

Then there is the ANSI Forth specification. It was written by a group of very smart people to benefit the community at large and to cover everyone's behinds regarding how they always implemented things for the last twenty years. It is a well written and clear document for its intents and purposes. But it is not a simple thing like a Forth implementation on a real computer can be. It is a formal description what makes a system compliant with the ANSI standard. It is meant to cover a lot of ground because it is meant to be portable on any type or size of machine or style of implementation.

I would not say that ANSI Forth compilers are not good or that they cannot generate good code. Far from it. I have written lots of them for different companies and they can generate exactly the same object code as some of the other compilers and with source code that is readable to a lot of people.

What I say is that ANSI Forth is just way too big and gives people way way too much room to stay with their bad programming habits from other languages. It certifies and standardizes on lots of bad habits.

At iTV we had programmers who knew ANSI Forth and programmers who didn't know Forth. We had some programmers who wrote exclusively in ANSI Forth, some in either ANSI Forth or Machine Forth, and some who wrote exclusively in Machine Forth. I was programming manager.

Chuck and I constantly argued with management and with the ANSI Forth programmers the following points. Anyone can implement a threaded ANSI certified Forth environment on any chip and only we have the advantage of writing in Machine Forth. We have lots of evidence that code can be written at the same speed in either environment but that it will be four to one hundred times smaller in Machine Forth and ten to a thousand times faster in Machine Forth so we should be doing more of that. We are trying to make a low fat computing product and we are letting a lot of fat get in this way.

One of the programmers would claim that 98% of the bugs that we were working on were simply the result of the illusion of portability and people's insistence that their code works because it was tested in the ANSI Forth development environment that they used. Porting the portable ANSI Forth code from one environment to another found lots of bugs where programmers were just not thinking about how to write portable code. They could not see the bugs in their development environment. Someone else had to port the code. Someone else had to debug the code. The programmers who did this debugging claimed that it was terrible that 98% or our time was chasing down all these bugs related to people's insistance that code was ANSI compliant and tested in their environment. The programmers who did not write code for the target environment would argue that the rest of the programmers were not spending all of their time fixing those kinds of bugs.

I would complain that we were trying to build a low cost, small memory product and that we didn't want to introduce fat. I would also argue that we needed to think of the target as what it was a system optimized for real time demands and minimal resources. When I would find examples of people using standard "portable" ANSI Forth routines from libraries that were 10,000 times slower than the way I would do it and that I could optimize by 100 times in a couple of hours that we needed to think about this portability idea more closely.

My favorite example was the jpeg image decode. A programmer who understood 'C' and ANSI Forth took the task. He translated some jpeg decode code from ANSI 'C' to ANSI Forth and compiled it into the system. It was buggy and the performance was terrible and it was shelved. Another programmer later took on the task. He had not been spoiled by ANSI Forth and knew little about it. He looked at the problem, thought it thru and wrote a little Machine Forth code and debugged it. One program was 100 times smaller and 1000 times faster.

A simple code profile of the various components in the software made it obvious which components were written in Machine Forth and which were written in ANSI Forth. In staff meetings one programmer would report that he got his module down from 3K to 2K and made it 40% faster and another would report that he had only added another 50K to fix his problem and that it was now too slow to measure.

Getting the ANSI Forth programmers to change any of their programming habits was like trying to pull teeth from an angry pit bull by hand. Chuck and I would argue that Machine Forth was so easy and so productive that they should at least try it. They might like it. Chuck and I would argue that Machine Forth limited you to good programming practices and that using ANSI Forth the way they were was making things way more complex than we needed or wanted. Some people got it, some didn't. Some people would just say that they were hired to write ANSI Forth, and this was the case.

What I see in Forth is a quintessential intellectual toolset.

: FORTH STACKS WORDS BLOCKS ;

What I see as the power in Forth is that it is interactive, real, and simple. You can get right down close to the metal and write the important functions to be as fast as possible and test them in a short amount of time. I really like knowing that when I write DUP that it is a 2ns opcode in our Machine Forth. That lets you write good code. If you don't know the relative speed of each system word how can your write good code? Well if good means having the potential if carefully written to have some portability at the expense of size and speed then yes ANSI Forth can be good code.

But like Chuck I think that the idea of Forth is to understand and optimize all those little fiddly details to give us a sense of doing the job right. In Machine Forth we have this list of 27 easy to learn and understand Forth opcodes that take 2ns. We took people who never learned ANSI Forth and taught them Machine Forth in an hour and had them programming an embedded wireless ethernet controller in it the next day. ANSI Forth is almost as complex as 'C'. There are hundreds of words that you have to learn to get started.

People were sensitive about so many people in Forth experimenting and doing things their own way. In the old days Forth was the most portable language because it was the easiest to implement. Then 'C' became a standard for portable code. People wanted something like that for Forth so they wanted to get everyone to agree that ANSI Forth was Forth.

I see ANSI Forth as little more than an agreement to officially recognize the pigeon hole where Forth can die. It can become one more failed attempt to find the ideal portable scripting language. I think Chuck sees it the same way. I didn't see it his way for years but it is one more thing where I have come to agree with him.

I feel insulted when people say that they know ANSI Forth and that they don't like Chuck using the word "Forth" in the title of his Machine Forth or Color Forth because it is too weird and there is now finally acceptance that

: FORTH dpANSForthspec ;

so he should not call what he is doing Forth any more.

It seems to me that a lot of people think that it isn't Forth if it isn't written in 'C'.

I would like to see $5 computers that are better than PCs. I would like to see Forth enable a new generation of very smart and cheap computers and enable a new generation of very clever children. I see ANSI Forth as an inefficient interactive portable scripting extension to 'C' and not at all in the spirit of Forth. I think that that is the disaster of ANSI Forth that Chuck was referring to.

Jeff Fox 2/27/99

I asked Charles Moore to look at this essay and comment.

In email on 3/5/99 he said about this essay:

I like your essays. That figures, since I agree with them. The last months I've thought heavily about these issues, with no useful results.

Ultra Technology
2512 10th Street
Berkeley, CA 94710