Re: Build your own Forth for Microchip PIC (Episode 837)

none Byron Jeff wrote:
In article <137sb0raq9lv503@xxxxxxxxxxxxxxxxxx>,
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote:
....

You are handcuffed in the sense that you would like to be able to download small amounts of code into ram and execute it. You don't seem to have enough ram to do this, not to mention not enough stack space, etc. Hence, a civilized development environment will be very much more difficult to arrange than on other platforms.

I see that I missed explaining something. Code isn't going into RAM. The
code is burned into the flash of the PIC. There's 4-8K of flash on a
typical 16F part now. And the only parts I'll even consider are ones
that can programmatically program their own flash.

There's more than enough space for code. Even if I tokenize, I wouldn't
put those tokens in RAM. RAM is strictly for stacks and variables.

The flash is the reason that I'm harping on the incremental development
model. It's slow to program, much faster to read. The flash is the
Harvard architecture part of the PIC. The Harvard architecture also
dictates that native code cannot be run from RAM anyway.

Thanks, it's a lot clearer now. But now a few more questions.

Is all your flash code space, or can you set it to be part code, part data? Because if you're doing tokens, wouldn't your token tables go in data space, with your token interpreter and primitives in code space?

In any case, even 8K is by no means generous for the code you'll need plus token tables.

....

The model I envision:

1. Prototype/test/debug words on host using tether to manipulate I/O
2. Compile words for target substituting local I/O access for remote ones.
3. Transfer words to target flash.
4. Retest word on target.

The difficulty I see with this model is that your host is *very* different from your target. You can't, for example, test any of your PIC code (of which there will be some, for your primitives at least, regardless of what model you use) on the host. And unless you make a token interpreter on the host as well, there's no way to test that logic.

The model that I don't want:

1. Compile all words on host
2. Transfer all compiled words to flash on target
3. Debug/test on target.
4. Rinse and repeat.

I can work that model perfectly in assembly, Jal, C, NPCI, Basic, or
any number of traditional laguages/development models.

I certainly sympathize with not wishing that model.

....
Tokens is the winner in my case too. Still a bit concerned about if I'm
constrained in my token size (or if it really matters).
Not really.

From what I was reading in Brad's article it seems to be possible to
implement the token interpreter so that variable length tokens are
doable. It's a model that I had already implemented for my bytecode
interpreter, so I have no problem with it. So for now that's what I'll
plan to do reserving some of the 8 bit token space for extended word
tokens. It'll make my life on the host a bit more difficult because I'll
need to essentially do some hamming encoding of words to make sure that
the most frequently used words are in the smallest token space. But
again that's an optimization issue, not an implementation one.

The usual approach is to have 1-byte tokens for your most common words, maybe 250 of them, and then use the few remaining tokens (e.g. FE) to signal that there will be a 2nd token used against a secondary table. So, unless you're planning really ambitious apps (which you're not) you never need more than 2-byte tokens.

....


I think that you may have convinced me to take a stab at an STC
implementation. It does eliminate the need for the address interpreter
and will speed up execution of the most critical part of the threading
mechanism. It'll save me the code space of a token table. It would be an
absolute no brainer of a decision for an 18F part (32 level addressible
stack). I figure that if I don't implement recursion it should be fine.

Well, that certainly precludes testing your definitions on the host in more than a cursory fashion.

And if not, I know that I have tokens as a backup.

Exactly how limited were those 8051 stacks?
64 bytes (32 cells) as I recall. Could have been 48 bytes. It's been a while.

Now we are talking about the hardware subroutine stack right? Just
making sure.

Yes. On the most limited 8051 parts we don't use the Forth return stack for return addresses, but the subroutine stack.

....

The execution model doesn't affect whether you can or cannot do incremental compilation. What determines that is whether you have a place to put the downloaded definitions to test them. You make it sound like the address interpreter is a big deal. It isn't.

From my reading (primarily Brad's articles) it's the core concept of
interpreted Forth. Without it you're back to the traditional compilation
model of inline expansion of native code. I already have a compiler like
that languishing on my hard disk. Not real interested in writing
another.

The address interpreter is a core concept of indirect-threaded code Forth. Other models work differently, and all may support incremental compilation.

...
I guess my question is what is the structure of an optimized compiled
code word then? What I cannot visualize is the linkages between the code
fragments.
It's code in code space. Small primitives or optimized code sequences are expanded in place. Larger words are called. Linkage is normal call/return.

So it's STC with inline expansion of smaller fragments. Got it.

I think that structurally I can easily see how to compile a definition
into a collection of addresses or tokens. However compiling native code
is a different animal.

Simpler, really.

If it's straight STC you're right it's simpler. Still a bit worried
about the PIC hardware call/return stack. If it overflows, your
application goes into the weeds.

If small primitives are expanded in line, there's less requirement for calls.

....
Plus I feel if I can pull this off in my constrained little box, that
moving the port to a roomier chip (like the propeller, which of course
due to Cliff I don't need to do) should be no problem.
Isn't that like saying, if I can learn to ride a unicycle, a tricycle will be easy?

No. It's saying I already know how to ride a unicycle, so the trike is
trivial.

But you *don't* know how to ride a unicycle, in the sense that you don't have your incremental, interactive development system on a PIC, and I suspect you're glossing over the difficulties of building one. A token-based executive, which you say you have, is the tip of the iceberg.

....
....
The target side of the XTL is very small and simple, probably not significantly different from Frank's concept. The host is rather more complex. And the concepts have been developed over about 20 years. There's a lot of advantages to be found in "standing on the shoulders of giants".

OK I'll take you on with this. Here are my requirements:

1. I need an environment that runs natively on my Linux box.
2. I need the specification of the XTL and the host wire interface.
3. I need complete documentation of the host environment.

Can you provide that? How much will it cost me?

More than is appropriate for a hobby/educational project (mostly the cost of the Linux port). But the documentation is at least free if you get a SwiftX evaluation package.

I see the distributed model sort of as a breakpoint. The host already
has everything (primitives, core words, core extensions) already
implemented. Why not use it as a remote process server in addition to
the text interpreter, wordlist coordinator, and the target's cross
compiler?
Yes.

You said no previously. Something to the effect that all words ran on
the target and that the stack was not transferred between the host and
the target.

So which is it?

Yes it's reasonable to use the host to provide the text interpreter, hold and manage dictionary heads, manage wordlists, and provide a cross compiler. And I don't think I said the stack is *not* transferred between the host and target, because it very definitely *is*.

No it's not reasonable to think that you can test your app definitions usefully by running them on the host. The host is more different than you realize.

...
I understand. We don't need the host to execute target code. The host is
running forth, the target is running forth. I do realize that they may
be implemented differently (different cell sizes and the like). But
forth is forth is forth. So if there's a word on the host that the
target can use, why is it necessary to compile that word for the target,
transfer the word to the target and execute the word on the target?

Because you need to test whether the target version works. It's different, regardless of the implementation strategy you use. To take a very basic example, you can assume that gForth's DUP works. How will you know PIC's DUP works without testing it on the PIC? If you're compiling STC for the PIC, how can you know you're doing it correctly without testing the generated code on the PIC? If you're using tokens, how do you know the token interpreter is working and tokens are being generated correctly without testing that on the PIC? Yes, to a limited extent you can test some high-level logic on the host, but that's the least of what you need to worry about.

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."
==================================================
.

Relevant Pages

  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... put those tokens in RAM. ... This is the reason I'm wanting to use the host as a remote execution ... Test/Debug code on target recompiling and reloading as necessary. ... of implementing anything other than a batch forth compiler for it. ...
    (comp.lang.forth)
  • Re: Build your own Forth for Microchip PIC: Design thoughts
    ... Embedded systems hardware I don't plan to buy. ... Advanced work would be a distributed model where the PIC and host work ... All the code on the target would be headerless. ... compile once and copy the code to the PIC, ...
    (comp.lang.forth)
  • Re: [RFC] [PATCH] Fix b43 driver build for arm
    ... the size of the structure on the _host_ where it is compiled. ... I can't see why we would want to check _anything_ of the target stuff ... I can compile an ARM kernel on any machine I want. ...
    (Linux-Kernel)
  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... inappropriate on a limited target, ... So it reverts back to the traditional compile ... platform for your target by using the host to implement your words. ... In short create enough Forth to execute the inner interpreter and you ...
    (comp.lang.forth)
  • Re: Build your own Forth for Microchip PIC: Design thoughts
    ... the host, then cross compile the word into its PIC equivalent for ... target's stack and tells the target to execute the "+" token. ... definitions into tokens or whatever code the PIC expects to execute. ... address and execute it on the target, compile it into the ROM image, ...
    (comp.lang.forth)