Re: Build your own Forth for Microchip PIC (Episode 837)
- From: dkelvey@xxxxxxxxxxx
- Date: Sat, 23 Jun 2007 19:39:35 -0700
On Jun 23, 10:21 am, byron@upstairs.(none) (Byron Jeff) wrote:
Hi folks,
I wanted to introduce myself and throw out some ideas in what I perceive
to be as a gap in the Forth continuum. Any feedback would be
appreciated. Sorry for the length but I've been doing a lot of thinking.
Feel free to snip whatever you like. I have a lot of setup here, you can
skip down about 150 lines if you are interested in only my questions.
I'm an IT professor at Clayton State University in the Atlanta area. So
my interest is primarily academic. I'm also a tool builder. The sense of
understanding and control I get when working with my own tools is
appealing. I'm also an Open Source and Linux guy. So I'll happily use
others' tools so long as I have the ability to adapt them to my needs.
Finally I'm a embedded systems guy that has been using Microchip Pics
for development of small scale embedded systems projects for years. I'm
well aware that the architecture is quirky and limited, but the
confluence of price, documentation, and simplicity has made it a choice
of mine for awhile. Plus Microchip offers free samples.
So where does Forth fit into this? Truthfully I wish that I had come
across it 15 or 20 years ago. The simplicity and elegance of Forth's
language/system concepts (stack based, generating/incremental compilation,
and interactivity) are intriguing. Forth came across my screen a couple
of weeks ago while I was taking a look at the Parallax Propeller:
http://www.parallax.com/propeller/index.asp
A $12 8 CPU multiprocessor embedded system that has a collective 160
MIPS of processing power and comes in a 40 pin DIP suitable for
prototyping is a wonder to behold. But the culture around the part also
illustrates why I like building my own tools. Parallax developed a high
level object language called Spin around the part. They embedded an
optimized bytecode interpreter for the language into the part. The
disheartening thing is that they then build the compiler and IDE
environment for Spin specifically for Windows. Worse is that the
source and specifications for the environment are closed. In short to
program the part in Spin you must use their tool on their platform.
Sigh.
Fortunately another developer, Cliff Biffle, who was in the same boat (a
Mac OSX guy) solved the problem by hosting Forth on the chip.
PropellerForth:
http://www.cliff.biffle.org/software/propeller/forth/index.php
requires only a terminal interface to get development done. In addition
Cliff has added words to facilitate multiprocessor tasking. So it's
possible to run multiple simulteaneous tasks on each of the 8 Propeller
cogs (CPUs).
Cliff's contribution got the ball rolling for me. Searching around let
me pretty quickly to Starting Forth, Thinking Forth, and Steven Pelc's
Programming Forth. I also installed gforth on my Linux box and started
noodling.
Fortunately for me stack based programming is old hat. Over the years
I've built interpreted languages for processing web pages, teaching
beginning programming, and programming PICs (combination of HLL compiler
along with a bytecode interpreter). In each I utilized the concept of an
execution data stack for processing expressions and subroutine calls and
parameters (when I implemented subroutines). But each time I approached
the high level language in the traditional compilation, parsing, code
generation/interpretation view of most high level languages. Forth's
view of the world instantly clicked with me.
So the next question for me was "What about forth for PICs?". As a long
time contributor to the Piclist mailing list, I can never remember seeing
a Forth discussion. Google of course popped out a handful of what are
the usual suspects: Picforth:http://www.rfc1149.net/devel/picforthand
Mary:http://mary.pepix.net. I'm limiting my discussion to Forths for
the 16F PIC family as that's my primary focus.
I played with Picforth for a few and quickly realized that it was in
fact a Forth compiler. I was disappointed because I feel that takes away
one of Forth strengths: interactivity and incremental compilation. For
years I've used Pic assembly and other languages such as Jal, and my own
PIC HLL called NPCI for development. As compilers you fall into the
traditional edit -> compile -> download -> test cycle. That's exactly
the cycle I wish to get away from. The ideal Forth for embedded
development would be interactive, with incremental development, and self
hosted so that when the application is finished, it's all onboard the
target. So the game's afoot!
c.l.f is a rich resource of discussion on the subject. Searches for PIC
Forth, minimal forth, target forth, and embedded forth came up with mega
threads of discussions that I've been pouring over. A couple of
observations:
1. A specification for hosting Forth with a minimal kernel would be
instructive for tool developers because it would abstract what one needs
to implement Forth in a particular environment. One of my maxims to my
students is "Make it work. Then make it pretty." In Forth's case I'd
change that to "Make it work. Then make it fast." The concept of minimal
kernels always gets shot down because of the resulting speed of the
result. However, if a developer can get Forth working on the target,
then optimizing words to make it faster can be done incrementally as you
move forward. One crack at this was done in this thread:
http://tinyurl.com/22c7sn
with the specification here:
http://www.quirkle.com/misc/forth.htm
While I think Jim has the wrong target audience, the general Forth
enthusiast, the idea has merit if targeted towards tool builders.
2. Such a specification should be architecture neutral. Specs for
eforth, hforth, and retroforth (which are often suggested when the
question "How do I build my own Forth?" come up) that I've seen seem to
be a bit too tightly coupled to the X86 platform. A forth specification
that factors out the primitives would be helpful. A tool builder is
probably going to target something that has not in fact been done yet.
3. For the purposes of embedded development, that an environment that
appears as close to self hosting as possible would be desirable.
Frank Sergeant idea is really close to being the jackpot. What could be
a simpler kernel than 3 instruction Forth?
http://pygmy.utoh.org/3ins4th.html
It's almost like Frank was thinking about me coming along 16 years later
when he wrote this. Elizabeth gives an explanation of the tethered Forth
approach to embedded systems development here:
http://tinyurl.com/yv6z99
In evaluating Frank's discussion I perfectly agree with why the
microkernel approach is the right one, put the simplest, easiest to test
executive on the target will get you going the fastest. Couple that with
a full fledged forth environment on the host, you can get rolling pretty
quickly.
However, I disagree with Frank's assertion that you actually have Forth
on the target. There's a gap between Frank's bytecode to execute
arbitrary code on the target and actually running Forth on the target.
So at long last we get to the gap I referred to in my opening. Frank's 3
instruction executive facilitates getting an embedded system connected
to a Forth host so you can interactively develop forth on the host and
exercise the target. But his XCALL instruction facilitates calling
arbitrary code on the target, not Forth code.
So the question is "Given an embedded micro, what is the minimum forth
environment required to execute Forth words?". If we can answer this
question then along with the memory read/write instructions it should be
possible to migrate Forth words (both code and compiled) to the target
and have them executed there. If you can incrementally migrate the
application to the target while developing it, then when you finish you
can simply disconnect the target from the host and run the entire
application on the target. All the while during development, you have
the full facilities of the hosted forth environment available for you to
interactively develop the application.
Brad Rodriguez's Moving Forth articles gives a pretty good idea of how
to pull it off:
http://www.zetetics.com/bj/papers/moving1.htm
Brad is of course very interested in how to implement such a kernel in
an optimized way. But again "make it work, then make it fast." comes to
mind. In my estimation one needs two sets of items to execute forth words:
1. The forth virtual machine including the standard registers and
stacks.
2. Three critical words: ENTER, EXIT, and NEXT.
In short create enough Forth to execute the inner interpreter and you
can get going.
It seems to me that neither of those two items are so complicated that
they could not be easily put together for a target. And Frank's 3 word
forth implements a inner-inner interpreter that can be used to create
the inner interpreter required to run forth words on the target.
Only one piece of the puzzle is missing at this point. Elizabeth
discusses in her post above that the XTL transfers the stack between the
host and the target. In short it implements a form of distributed
execution where you muster the stacks for RPC. In doing so one can run a
application with a set of words distributed between the host and the
target.
So I envision an environment where Forth words are quick interactively
developed on the host. Once satisfied they work, they are incrementally
compiled on the host and transferred to the target. applications can be
a set of shared words between the two until complete at which point all
needed words are transferred to the target, completing the app.
There are still details that need to be worked out such as how to
differentiate between local words and remote words in both systems and
how to facilitate transferring the stacks between the two. In both cases
solutions should be geared towards simplifying the target.
I do believe that the minimal kernel still needs to be specified. It'll
give a list of words that needs to be implemented, tested, and
incorporated in the initial kernel. I can help here
read more »...
Hi
You should look into CMForth that was used on the NC4000. It had a
relatively simple cross compiler that is relatively easy to convert to
another platform. It is a little confusing at first because many low
level words exist as machine level words and are only binary codes.
Still, the entire FORTH is relatively easily recompiled. I've done
this many times myself to make changes or enhancements.
Dwight
.
- Follow-Ups:
- References:
- Prev by Date: Re: Build your own Forth for Microchip PIC (Episode 837)
- Next by Date: Re: Build your own Forth for Microchip PIC (Episode 838): Threading
- Previous by thread: Re: Build your own Forth for Microchip PIC (Episode 837)
- Next by thread: Re: Build your own Forth for Microchip PIC (Episode 837)
- Index(es):
Relevant Pages
|
