PFAVR -- An ANS Forth Implementation for the Atmel
Padnos School of Engineering
Grand Valley State University
I was motivated to investigate Forth for the Motorola 68HC11 by noting
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
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
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
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
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
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:
- 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
- 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.
- PFAVR is not particularly fast. Key parts of it could be
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.
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.
- ANS compliant
- reasonably small, hence...
- easy to understand (in my opinion), hence...
- easy to modify
Why write another Forth for the Atmel AVR when others were available?
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: firstname.lastname@example.org