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

byron@upstairs.(none) (Byron Jeff) wrote:

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.

I can sympathise. Sometimes it seems like there's always something else
to do first before you can do the thing you want.

But if you want to use Forth, you need to learn how to use Forth. That
doesn't need to take a long time, but it's a necessary step. So get some
Forth compiler and practice with it. Elizabeth's product isn't the only
free one that works, but her manual is very good. If you use a different
one, choose one with a good Forth manual. Write some sort of
applications to learn Forth. You learn more by doing than by watching or
pretending to do. You don't have to use somebody else's cross-compiler
model but the more of it you can use the less you have to re-invent for
yourself. That's a plus.

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.

I see! So you might want to write and test a whole block of code with
your simulator, and then when you can fill a whole block of your flash
then transfer them all at once.

On the host you'd still want to keep track of the addresses to call on
the PIC so you could test them easily. It looks like the concession
you're making to reality here is that you want to flash blocks at a time
and do your final testing for whole blocks of words at once, in the hope
that you'll only have to do it again a few times.

Use the same parsing words, same logic,
just feed to a different version of :, CREATE, VARIABLE, etc.

OK that makes sense to a point. In the XC stuff that I've read (along
with Stephen's chapter on the subject in the Programming Forth book)
this is done via words that defines the environment (wordset?) you're
currently operating on. Switches are done via words such as HOST,
TARGET, INTERPRETER, and the like.

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.

One way is to put the word in a file, and load the file. And then you
might as well keep your tests in a file too. Maybe keep a history file
and edit away the parts you don't want. When I first started I used to
do whatever tests I happened to think of at the keyboard. That worked
very well. But your test suite is part of the documentation, and if you
someday wind up doing it again or something similar, why should you have
to re-invent everything from scratch? And if you later find an error
your tests didn't uncover, you might notice why you didn't think to
check it the first time around, and that will improve your testing
skills. So if you're going to put all that stuff in files anyway, why
not just use them again? And then there isn't much improvement to
compile once and copy the code to the PIC, versus recompile. You save
processor time, which is completely irrelevant. On the other hand, if
you use absolute addressing or absolute jumps, you *need* to recompile.

: add2 2 + ;
: add4 add2 add2 ;
5 add4 . 9 ok

Being happy with the result, let's get the word into target space:

add4 picompile ok

You can do that. The easy way, you do

' add2 picompile
' add4 picompile

so you don't have to look up each command it calls to make sure they're
already compiled.
You want your code to use relative jumps and relative calls, right? So
in the best case you can just take your block of code and pass it to the
PIC and flash it. That shouldn't be too hard.

Now add4 refers to a word (add2) that's currently not compiled in the
target space. It would be nice to have a transparent compilation of
that additional word into the target space too.

You can do that too but it's a little harder. You want to compile each
of the words it calls, recursively. You want to recurse your way down to
a word that doesn't call anything new and compile that before you start
compiling anything else. I think you'll probably have to give up
single-pass compilation to do that, but maybe not. It's potentially a
lot of complication compared to just checking for yourself. If it was me
doing it, I'd think about how much code I was going to write that needed
it, and I'd probably put off doing that step until I noticed I was
making errors without it. If you put your time into whatever looks like
the limiting factor now, it's likely to give you faster progress.

1. Words for accessing dictionary definitions like SEE does?

Like SEE ? Ah. You get an xt, or anyway the address of a call, and you
want to find the name. The newer Forth standards don't give you any way
to do that since some Forth systems can't do it easily. The Forth-83
standard let you do that, I think. There was a word like >NAME . I don't
remember whether you had to do >BODY >NAME or some other combination.
You might check the documentation of your particular Forth, or look at
the code with DUMP or something like that to see how it's actually laid
out.

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

EVALUATE . or LOAD for up to 1024 characters.

3. words to address allotted memory in the dictionary?

HERE 256 cells allot CONSTANT MY-DATA
ok
MY-DATA U.
ok 21063284

Give it the name to get the base address. Add whatever offset you want
from there to get later addresses.

CREATE MY-DATA2 32 CELLS ALLOT
MY-DATA2 acts just like MY-DATA except the code gets compiled first.

When the one thing that's most getting in your way is that you don't
know Forth, it looks like learning Forth would be the limiting factor
that deserves some effort.
.

Relevant Pages

  • 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: 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. ... 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 ... ... What you need to do is feed your tested source to a different compiler that will generate PIC code and download it. ...
    (comp.lang.forth)
  • Re: Moving from 8051 to AVR
    ... C was largely based on the "B" language, ... compile to native machine instructions, ... using methods suitable for embedded systems, ... target and for an ARM target. ...
    (comp.arch.embedded)
  • Re: Moving from 8051 to AVR
    ... C was largely based on the "B" language, ... compile to native machine instructions, ... using methods suitable for embedded systems, ... target and for an ARM target. ...
    (comp.arch.embedded)
  • 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)