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

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.

....
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).

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. And what your resident Forth compiled cannot be executed on the target.

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

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.

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).

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.

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)
    ... Finally I'm a embedded systems guy that has been using Microchip Pics ... disheartening thing is that they then build the compiler and IDE ... Forth, minimal forth, target forth, and embedded forth came up with mega ... There's a gap between Frank's bytecode to execute ...
    (comp.lang.forth)
  • Re: Build your own Forth for Microchip PIC: Design thoughts
    ... Embedded systems hardware I don't plan to buy. ... the flash write speed often dominates the transfer time. ... TARGET, INTERPRETER, and the like. ... compile once and copy the code to the PIC, ...
    (comp.lang.forth)
  • Re: Build your own Forth for Microchip PIC: Design thoughts
    ... that exist in one environment to transfer and compile that word ... A proper cross compiler will allow: ... Don't you need a TARGET in front of that definition? ... Flash is slow to load. ...
    (comp.lang.forth)
  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... the unreasonablly small hardware stack size for my particular target. ... You are handcuffed in the sense that you would like to be able to download small amounts of code into ram and execute it. ... because once you do away with the inner interpreter, ... An optimizing compiler isn't a post-processor, it's an *alternative* to another kind of compiler. ...
    (comp.lang.forth)
  • 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)