Re: Build your own Forth for Microchip PIC: Design thoughts

In article <1387v9jhn2jdj44@xxxxxxxxxxxxxxxxxx>,
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote:
none Byron Jeff wrote:
In article <1386p75reqrcad4@xxxxxxxxxxxxxxxxxx>,
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote:
...

Yes, this is why I recommended you get a free SwiftX cross-compiler and
experiment with it for a while. Write some Forth apps and make them
work on some processor SwiftX supports (since the boards are cheap and
you aren't developing any new hardware it should be non-traumatic).

Elizabeth,

All the above suggestion does is divert focus away from my real problem.
You outline 4 things that I don't really need:

1. A Forth product I don't plan to use.
2. Embedded systems hardware I don't plan to buy.
3. Applications that I don't need to write.
4. A development model that doesn't fit the model I want to use.

As we have discussed elsewhere in this thread, I'm only a novice to the
Forth language. For programming in general, embedded systems development,
and the like I know my way around the block.

Getting a little more experience with Forth and Forth cross-compilers
would help you more than you realize.

Until I get this going I'll be working with gforth and picforth. My
interns and I do have projects that we need to get done.

...
The normal way of things is that you load on your host a cross-compiler
that looks just like the resident compiler, but generates PIC code. So,
no such thing as picompile, just process the source in the same way but
you get pic code, ideally automatically downloaded.

I got that from my readings. But it doesn't really address the model of
testing words on the host, then transferring words to the target. The
reason is that most forth embedded systems targets are RAM based and
therefore can be loaded at wire speed. However, in flash based
environments, the flash write speed often dominates the transfer time.
In addition flash does have some (and often severe) write cycle
limitations. So a "test many, write once" model has some merit.

The same model works on flash-based systems. There are obviously
differences in timing, but we have used parts where all code space is in
flash.

It's certainly possible to test your high-level application code on the
host. I teach an advanced Forth course in which students write a
project (traffic light controller) simulated on a PC. In one course,
where the students would be ultimately working with a cross-compiler, I
showed them how to download their completed apps to a 68K target which
they'd never seen and they all worked with very minor changes (they had
to put INTERPRETER before their CREATE ... DOES> defining words, if any,
and TARGET after).

That's closer to the model I'm after. Truly I want a seamless blended
environment where there's no distinction between the target and the
host. What I'm proposing is a first step to get there.

However, it's also possible to use the cross-compiler to test your
PIC-specific code, which can be extremely helpful.

...

What does not seem to be addressed is my specific point of wanting words
that exist in one environment (HOST) to transfer and compile that word
on the other side of the fence. In other words I'm looking to avoid the
following sequence:

HOST
: add2 2 + ;
5 add2 . ( do a bit of testing ) 7 ok
( it works so let's get it to the target )

TARGET
: add2 2 + ( why do I need to retype it? ) ;

I already have the word I want in the host wordset. I don't want to have
to repeat typing it (and all of its error filled possibilities) in the
target wordset.

What you're missing is that, once you type in that definition its source
no longer exists, just the version that's compiled and ready for
execution.

I do understand that. What I don't understand is how words like SEE do
their work. SEE has to backtrace the XTs in the compiled word back to
the names that the XTs map to. How does that happen?

And what your resident Forth compiled cannot be executed on
the target.

I don't want to execute that compiled code on the target. I want to get
the word names that represented in the definition and then take those
names and recompile them for the target. In gforth (or any other for
that matter) how does the following sequence work:

: add2 2 + ; ok

see add2
: add2
2 + ; ok

The first line clearly compiles the word add2 on the host. The SEE
command displays the names of the words of the definition. It decompiles
the definition. How does that work?

What you need to do is feed your tested source (from keyboard or file)
to a different compiler that will generate PIC code and download it.

That's the traditional way of doing it. I'm searching for a different
model.

You can certainly do this one definition at a time (although a few at a
time would be more convenient), but you can't transfer compiled PC code
to a PIC and expect anything useful to happen.

Nor do I. I want the NAMES in the compiled host definition, not the XTs
or the compiled code. See gives the names of the words. I just want to
programmatically get that back and feed it to the parser of the cross
compiler.

Transparency is useful once you have the underlaying system working.
However, it's not your friend when you're trying to understand how to
develop the infrastructure you're wanting to implement. That's why I
motivated my example with an explicit word for the activity.

...
To reiterate my questions:

1. Words for accessing dictionary definitions like SEE does?

SEE accesses the compiled version. It isn't hard to do, look at how SEE
is defined in gForth. But I'm not sure it's useful for what you're
trying to do.

See above.

2. Parsing from somewhere other than the input buffer. Or alternatively
how to transfer text into the input buffer without typing it?

If you have text somewhere that you wish to parse, just pass it to
EVALUATE (which takes the addr and length of a string and passes it to
the text interpreter).

Excellent! Will take a look.

3. words to address allotted memory in the dictionary?

@ and ! and friends access "data space" in Standard Forth. On many
resident systems that's integrated with the dictionary, but in embedded
systems it's usually separate. We have words T@, TC@, T!, and TC! for
target data space, and CT@ etc. for accessing code space. Host @ and !
etc. are switched to use the appropriate target versions during
cross-compilation. There are also versions of ALLOT, etc., for
allocating space in various memory sections. See the XC standard for
details.

I can see the variations. All the accesses I want are on the host. So
it's probably integrated. I'll work with the examples in the other post
to see how to get it done.

Thanks for the help.

BAJ
.

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
    ... compiler is the only task that's burning in my brain right. ... that puts PIC code on the host for the simulator to execute. ... I'm not so sure about the simulator. ... That target will execute compiled forth words. ...
    (comp.lang.forth)
  • Re: tiny embedded C-based forth
    ... It would seem that both target and host ... and even though the compiler is simpler the language isn't. ... a Goods and Services Tax (or almost any other broad based production ...
    (comp.lang.forth)
  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... a powerful desktop, you can do things that are both difficult and inappropriate on a limited target, such as compiling optimized target machine code. ... The actual compilation is on the host, but the download of the result is immediate. ... because once you do away with the inner interpreter, ... through an optimizing compiler removing the inner interpreter altogether ...
    (comp.lang.forth)
  • Re: Forth 10 times slower than C?
    ... make different implementation choices than a cross-compiler, yielding a small target footprint in exchange for a less-powerful compiler. ... the MPE cross-compiler will generate much faster code. ... As I haven't used it, I can't comment on its ease of use or interactivity, but if it is in the class of "umbilical" Forth cross-development systems you can have excellent interactive development support without compromising performance. ... It generates optimized native machine code, and also supports a fully interactive development style that's virtually identical to running a target-resident Forth, except that the target kernel is only about 6K. ...
    (comp.lang.forth)