PFAVR -- An ANS Forth Implementation for the Atmel AVR

Andrew Sterian
Padnos School of Engineering
Grand Valley State University


Top-Level | Glossary | Compiler Design | Rationale | Notes
Version 1.2

February 28, 2004
Motivation | Why pForth | Other Solutions

Motivation

I was motivated to investigate Forth for the Motorola 68HC11 by noting how inefficient the edit-compile-link-download-test process was in a college class and as part of the GVSU Firefighting Robot team. We have been using BUFFALO on Axiom CMM-E9 development boards and the GNU GCC tools for the 68HC11 to develop programs in C. BUFFALO was effectively serving as nothing more than an S-record loader. To write a simple monitor to continuously display what bits were set in Port E, for example, required an investment in the edit-compile-link-download-test cycle. My goal was to replace BUFFALO+C with a single language that could do both: interactive manipulation of the hardware and program development.

I had used Forth as a student many years ago and was impressed by its elegance, its small size, and its ability to function well as both an interactive exploration language and a low-level program development language. I was convinced that my students would benefit from the higher level of interactivity, spending more time with the 68HC11 hardware and less time finding and fixing bugs in C code (that's reserved for other classes).

I investigated some existing Forth implementations for the 68HC11 but did not feel that any of them were exactly what I wanted. I decided to port an existing Forth implementation to the 68HC11, customizing it along the way. This process was also intended to be a good re-introduction to the language (and it was!) After settling upon pForth as the implementation to customize (why pForth? see below), the rest was just a natural development process, and the result was PF11, a port of pForth to the 68HC11.

Recently, I decided to "modernize" and use the Atmel AVR's instead of 68HC11's. Porting PF11 to the Atmel AVR's did not take very long -- a testament to the portability of pForth.

There are many "Forths" out there, each oriented towards a different target audience and operating environment. My main objectives were:
As a result of the above objectives, PFAVR does not do as well along some dimensions as other solutions:

Why pForth

PFAVR is a heavily modified version of pForth, a public domain Forth written in C. After looking at various Forth implementations, pForth was the one I chose as the basis for PFAVR because it was:
The anti-pForth, for example, is gForth, the GNU implementation of Forth. Although gForth is an excellent tool and very useful for Forth work on modern computers, it is a very "big" Forth, with lots of features and doodads. I could not even begin to consider porting gForth to the AVR due to gForth's size. But pForth seemed to be not-too-far from a AVR implementation, and it turned out to be so. Still, pForth implemented a good part of the ANS standard, despite its simplicity.

Other Solutions

Why write another Forth for the Atmel AVR when others were available? Here are some of the other solutions I looked at and some reasons behind why I rejected them.

IRTC Cross Compiler

The IRTC cross compiler is neither free not a true interactive Forth.

SwiftX AVR Forth

Forth, Inc. provides many cross compilers for a variety of hardware systems, including the AVR. As with the IRTC compiler, the SwiftX product is neither free nor interactive.


© 2003-2004, Copyright by Andrew Sterian; All Rights Reserved. mailto: steriana@claymore.engineer.gvsu.edu