Re: Build your own Forth for Microchip PIC (Episode 837)
- From: Elizabeth D Rather <eratherXXX@xxxxxxxxx>
- Date: Sat, 23 Jun 2007 09:52:06 -1000
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.
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.
There is at least a draft proposal for a cross-compiler addendum to ANS Forth, at ftp://ftp.forth.com/pub/ANSForth. The actual proposed standard is in XCtext5.doc, and non-normative explanatory appendices in XCapp5.doc. There are also pdf forms. The '5' indicates that this is the 5th draft, following an extended public review period.
(NOTE: at this moment, 9:30 am Hawaii time on 6/23, that link isn't working. I'm trying to find out why and get it fixed. Meanwhile, if you really want the docs now, email me erather {at} forth {dot} com)
3. For the purposes of embedded development, that an environment that
appears as close to self hosting as possible would be desirable.
... Elizabeth gives an explanation of the tethered Forth
approach to embedded systems development here:
http://tinyurl.com/yv6z99
Yes, this abbreviated description is consistent with the draft standard above. It was developed jointly by FORTH, Inc. and MPE in the late 90's, and both FORTH, Inc. and MPE have been developing and using cross-compilers that work this way since then. It's very mature and well-understood technology.
That said, improvements do occur. By hosting the actual compilation on a powerful desktop, you can do things that are both difficult and inappropriate on a limited target, such as compiling optimized target machine code (which we do). The compile-to-optimized-machine-code approach not only generates much faster code than the traditional indirect-threaded approach, it's comparable in size on even small targets such as the 8051, and significantly smaller on larger ones such as the 68K family.
....
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.
Well, obviously that depends both on the overall architecture you're using (e.g. compiling optimized machine code vs. supporting an indirect threaded model), not to mention the needs of the applications you're going to be using it for. For example, if you know you're going to be doing a lot of certain kinds of functions (e.g. string management or double-length arithmetic) you'd go with code implementations of those key functions from the get-go, rather than having to go back and optimize them later.
...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.
Except that if you compile to code NEXT goes away, and ENTER/EXIT are merely subroutine call/return machine instructions.
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.
Indisputably the traditional indirect-threaded model is easier for newbies to implement, but may not be satisfying for challenging or time-critical applications.
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.
That tends not to be satisfactory, because most embedded apps feature custom I/O, so real target-specific words can't be tested on the host without your having to develop simulators for the I/O functions. It's a lot easier to just go with a fully functional XTL and do all your testing on the target. Among other benefits, that means you can use Forth to debug your target hardware, which is wonderful.
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.
That differentiation is typically done with wordsets (formerly known as vocabularies). The draft standard identifies "scopes" of words for the host, cross-compiler, and target; they are usually implemented with wordsets, although the draft standard doesn't mandate any particular implementation strategy.
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 because as I stated
earlier my NPCI bytecode interpreter implements a stack based virtual machine
and is written in pic assembly for the 16F family. It has debugged code
for all 16 bit arithmetic and logical ops, number processing for stacks, and conditional/unconditional jumps. It already implements an IP for the
bytecode.
Well, that sounds useful. Frankly, the reason so little Forth work has been done on the PIC family (and PICForth is so minimal) is that its instruction set is really a bit below the mark for a reasonable implementation. The PIC18 should be do-able, although we haven't yet seen much demand for it.
I look forward to hearing your comments on these thoughts.
I think it would be a good investment of your time to take a hard look at existing mature Forth cross-compilers. You can get a CD with extensive docs and links to free evaluation versions of our SwiftX cross-compilers for many chips (8051, 68HCS08, 68HC11, MSP430, AVR, ARM, 68HC12, 68K family, Coldfire, more) for only $15. You can get supported boards for most of these processors very inexpensively. The evaluation compilers are limited only in the size of the target app you can develop, so you can exercise them and learn a lot. For more info go to http://www.forth.com/embedded/index.html.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
.
- Follow-Ups:
- References:
- Prev by Date: Re: RFD: Reworking of TO
- Next by Date: Re: Build your own Forth for Microchip PIC (Episode 838): Threading
- Previous by thread: 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
|
