Re: Build your own Forth for Microchip PIC (Episode 837)
- From: byron@upstairs.(none) (Byron Jeff)
- Date: Sun, 24 Jun 2007 12:32:57 -0500
In article <467e54c7.517443265@xxxxxxxxxxxx>,
Stephen Pelc <stephenXXX@xxxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 23 Jun 2007 12:21:29 -0500, byron@upstairs.(none) (Byron Jeff)
wrote:
Elizabeth has explained enough of the mechanics that I won't repeat
here explanations. By the way, I'm a Stephen not a Steven.
I'll keep that in mind. BTW thanks so much for making your excellent
book available online. It's helped me get up to speed.
The problem with PICs for Forth is that the early ones are based
on a 1970s architecture for a minicomputer I/O processor. The
benefits of PICs are in the price and the peripherals. An
undoubted benefit for hobbyists is that you can still get them
in DIP packages.
That along with the fact that they are virtually indestructable makes
them an excellent platform for hobby use.
For commercial vendors of Forth, the price point of the
standard tools does not make PICs a very attractive target,
especially as high-end PICs are more expensive than low-end
ARMs. The PIC18 was the first Forth-friendly PIC, but these
days has little to offer unless you are already a PIC user.
Exactly. Being an existing user and tool developer is probably the only
reason I'm still contemplating implementing forth on that platform.
Within MPE, the question of supplying a PIC system is raised
every year or so, and we always end up saying "not unless
a client sponsors it".
And with other tools available that may be slow in coming. However
having freely available hobby forths for the platform out there may
generate enough interest someday to make a commercial version a
possibility.
So the question is "Given an embedded micro, what is the minimum forth
environment required to execute Forth words?".
It has been done many times using: fetch, store, execute. For a
Harvard architecture you'll also need fetchcode and storecode.
Now is there an underlaying specification of how to implement the rest
of the core words using those primitives? BTW I did take a quick peek at
the smartcard tokenized VM. At first glance it seemed heavyweight.
Implementing an Umbilical Forth this minimalist way may lead to
slow interaction, especially when Flash programming has to be
taken into account.
Slow is OK for starters. That's why Frank's implementation shows a
glimmer of merit. Couple it with Bruce's example simplified model
outlined in his other post and it doesn't seem to be too terribly
complicated to get started with a slow forth.
I realize that the real challenge is making a fast, compact memory
footprint forth. But my methodology is to iterate towards that as a
goal. Initially even if it's two words per second, it's good if it
works.
You should also note that starting from the three-instruction
idea and getting to a seamless interactive Forth requires a
great deal of patience and attention to detail - it's not a
quick job.
But as I've pointed out I actually have a written, tested, and working
stack based executive kernel from my NPCI bytecode interpreter. It took
a while for me to write and test it initially. But it's fairly complete
and can quickly be pressed into service. All I needed was a hook to get
an umbilical forth going to that executive. Frank's idea provides that
bridge.
There were about three Rochester Forth conference papers on
the topic in the 1980s.
I'll go back and take a look for them. Maybe forth.org has them online.
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.
Don't make implementation assumptions at this stage! For
example, Chuck Moore might well say that an eight-deep return
stack is always enough. Providing that you know about it,
that's enough for serious work. It's even better if you
can force a satisfying crash on overflow.
The last part is what I worry about. The pic hardware stack is a
circular buffer. There isn't any error condition when the stack is
overwritten. It does it sliently. Eventually the program will go into
the weeds and there will be no indication as to when that happened.
But I'll take your's and Elizabeth's expert advise on being able to
function with an 8 deep stack. The STC (with a bit of inlining) is in
fact the most simple and the most efficient code generation technique
off the bat.
It's no coincidence that both Forth Inc and MPE focus on
native code compilers, and MPE at least is much more likely
to use a byte-code token system when space is an issue rather
than an ITC or DTC system.
It only took understanding the fetch process of a program memory word to
eliminate each of these two as a possbility. I know tokens are doable
because NPCI operates on tokens. But STC would be the most efficient
implementation.
Thanks for the comments,
BAJ
.
- References:
- Build your own Forth for Microchip PIC (Episode 837)
- From: none
- Re: Build your own Forth for Microchip PIC (Episode 837)
- From: Stephen Pelc
- Build your own Forth for Microchip PIC (Episode 837)
- Prev by Date: Re: Build your own Forth for microchip PIC (Episode 839)
- Next by Date: Re: Gforth and gcc "progress"
- 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
|
