[<<][staapl][>>][..]
Thu Sep 4 17:02:50 CEST 2008

microchip forum post

First, i'd like to point out that it is possible to use Staapl without
the metaprogramming.  I've tried to be careful to not let high
abstractions get in the way when problems are simple and don't call
for them.

The website contains a couple of tutorials for this, and Staapl's main
test application (a sound synthesizer) is of that class.

The only thing that's generated there is a lookup table of note
frequencies, a geometric series.  This is the Scheme code that
implements that macro:
http://zwizwa.be/darcs/staapl/staapl/pic18/geo.ss

For the metaprogramming, I'll macro-expand the sales pitch a bit. I
haven't found a concise way to introduce the idea to people not
familiar with both Forth and Scheme..

> Staapl is a collection of abstractions

A library of scheme functions and macros

> for metaprogramming microcontrollers

that can be used to construct programs in a lower level language based
on Forth, and interactive code for testing program operation.

> from within PLT Scheme.

Staapl integrates with PLT Scheme's macro/module system, a solid base
for writing large applications and domain specific languages.  The
main point is that all name space and name scope management is PLT
Scheme's.

> The core of the system is a programmable code generator

Think of it as a macro assembler which uses a stack to pass arguments.
This leads to a prefix assembly language, instead of the normal
postfix OPERATOR OPERAND ...

> structured around a functional concatenative macro language

The 'concatenative' part is where the ease of metaprogramming is
hidden: composition of programs is just concatenation of strings.  (
This is how PostScript is mostly used. ) The macros are not quite
Forth, but a side-effect-free higher-level version that makes the
Staapl core a lot simpler.

> with partial evaluation.

This is basicly 'constant folding' optimization, but it is also used
to write template code.  A concatenative functional language makes
partial evaluation almost trivial.

> On top of this it includes a syntax frontend for creating Forth style languages

The core is not Forth, but I've added a frontend that looks a lot like
Forth.  This is historical, since the original idea was to build a
forth compiler, but the core evolved into a different language.

> a backend code generator for the Microchip PIC18 microcontroller architecture

A standard macro set implements a stack machine layer for the
PIC18. I'm working on 12 and 14 bit cores.

> and interaction tools for shortening the edit-compile-run cycle.

One of the great benefits of Forth is its interactivity: with the
target chip running, you can create new functions and try them out.
However, Staapl is not self-hosted (not stand-alone) so interactivity
needs to be simulated.  This allows to use interactive development on
tiny chips.


Now, why does this matter?  The original goals of this project are basicly:
* Interactive Forth development for tiny chips.
* Easy generation of code that has a large amount of red tape, but is
   difficult to express in a low-level language.

The first one is really just standard Forth approach. If you've never
tried it, give Flashforth a try. ( http://flashforth.sourceforge.net )
It stays closer to traditional Forth.  Staapl's Forth is more
optimized for the integration with Scheme.

The latter one is more ambitious and is heavily inspired by the
Lisp/Macro approach of writing domain specific languages.  This is
sometimes called model-based design/development: use high level
descriptions to compile to low level form.  Add to this that Forth is
very simple to generate, and you have a high+low level system that is
impedance-matched.

The problem is that for small projects, this approach is overkill.
I'm aiming mostly at large code bases which contain a lot of
parameterization.

I'm working on a USB driver framework that's written using such an
approach, USB containing a significant amount of red tape to make you
want to keep separate specificiation and implementation (which then
becomes a special purpose translator from specification to concrete
code).

If this model-based idea rings a bell, drop me a line.  I'm looking
for concrete problems to apply this to ('compiling' specifications).


                     * * *

    quote:

    ORIGINAL: DavidP5

    I know that functional languages can be quite helpful in language
    translation. The purpose of this Staapl system seems to be for
    translating from one language to another (in this case Forth-style
    languages are translated, using the functional language Scheme,
    into PIC18 assembly code?). So it seems that you can create your
    own Forth-style language and then use this system to make your own
    compiler for the language. But, I'm sure you would have huge
    reservations about such a plan for microcontroller code
    generation. I would be interested inhearing from the OP whether I
    have this correct.



There are 2 translation phases involved.

1.

The Forth macro language translates concatenative code to machine
code.  To port this to a new target, some key macros need to be
defined that generate the appropriate machine code for a simple set of
primitives. Optionally, this can add some optimizations.

Most of the core compiler is reused. This layer mostly presents a
'generic microcontroller' to the upper layers if desired. It's
perfectly feasible to use this Forth language as a programming
language by itself.


2.

Code for this basic lowlevel Forth language can then be generated from
within Scheme. This is if you want to use the 'generic
microcontroller' stack machine as the machine to target your
domain-specific description language.



[Reply][About]
[<<][staapl][>>][..]