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:

A completely free implementation so that others would be free to study it, modify it, and improve it
A minimal implementation with very few bells and whistles so that custom C code could be added and still fit into less than 32K
An implementation in C so that it could be modified, and even ported to other 8-bit processors, with as little effort as possible
ANS compliance as much as possible
A 16-bit Forth. The AVR is an 8-bit processor and can stretch to work with 16 bits. A 32-bit Forth just doesn't make sense for this chip.
A native Forth, not a Forth compiler that generates AVR code. Remember, I'm trying to get away from the edit-compile-link-download-test process. A Forth-to-AVR compiler doesn't really confer any advantages in this respect.

As a result of the above objectives, PFAVR does not do as well along some dimensions as other solutions:

PFAVR is not particularly fast. Key parts of it could be rewritten in assembly language to improve speed, but this would affect maintainability and the ability to quickly customize the implementation.
PFAVR is not as small as it could be. Again, an assembly language reimplementation would greatly shrink the code footprint.
PFAVR absolutely needs external RAM, reducing the number of AVR chips that can be used. Native code or umbilical Forth implementations can get by with just internal SRAM.

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:

free
ANS compliant
reasonably small, hence...
easy to understand (in my opinion), hence...
easy to modify
well-written
well-established

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.

Motivation

Why pForth

Other Solutions

IRTC Cross Compiler

SwiftX AVR Forth