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

In article <20070628192024.65040d58.j2thomas@xxxxxxxxxx>,
Jonah Thomas <j2thomas@xxxxxxxxxx> wrote:
byron@upstairs.(none) (Byron Jeff) wrote:
Jonah Thomas <j2thomas@xxxxxxxxxx> wrote:
byron@upstairs.(none) (Byron Jeff) wrote:

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.

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.

I've been noodling with basic constructs. For me the only way to get a
feel for a language is to write a real application in it. This
compiler is the only task that's burning in my brain right. So I'm
going to jump into the deep end of the shark pool and take a swim.

OK. It sounds like a good project. Maybe you can break it into little
pieces and start with the ones you know how to do.

High level design is helpful. I've already learned one poor assumption
already just from the replies I've gotten.

The problem I'm having is that there's a pretty significant disconnect
between tutorial work and the tasks I want to do. I learned more about
what I wanted to pull off from Brad's Writing a Forth Assembler than
any of the three books I studied or the numerous guides/tutorials I've
read. There's a bit of a different skillset doing systems work as
opposed to application work.

In Forth, pretty much everything you're talking about is advanced
application work. Some of it is basic applicsation work.

I'm trying to get up to speed with advanced applications as quickly as I
can.

1. Get the next word from the definition
2. Look up the pic address for the word
3. Generate a call to the pic address.
4. Write the compiled call to the end of the pic compiled definition.
5. Repeat 1-4 for each successive word to the end of the definition.

OK. You want to have a variable that holds the first available code
address on the PIC.

Yes.

When you compile a command, you make a definition
on the host that returns that address.

OK.

You also make a second definition
that puts PIC code on the host for the simulator to execute.

I'm not so sure about the simulator. The host is going to be tethered to
a real hardware target. That target will execute compiled forth words.
There's a debate as to whether or not a simulator needs to be in the
middle of this.

Whenever you compile more code into the simulated definition,

Let's call it the target definition.

you increment the
variable to remind you about the PIC memory you're using up.

Agreed.

So you can compile source code, and each word tells you the PIC address.

Bingo.

Making the call to that address and writing the code to the end of the
current definition ought to be easy.

I believe so.

Your simulator has to use PIC addresses and convert them to real
addresses to call, but that's easy.

Again not so sure about the simulator. I've always been thinking about a
test on host, compile and load to target, test on target model. A
simulator would either have to be an external application or would have
to be written in Forth. I'm really not trying to compound my problems
right now.

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.

Right. So test the word(s) on the host and do a limited number of
writes to the target. It's antithetical to the forth way because
generally forth machines operate from RAM.

It looks to me like a slight complication.

Just an observation. Most of the tethered environments seem to target
seamless compilation and instant downloading along with only target
testing. RAM on the target facilitates all of these activities.

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.

Now that's a thought. You'd need some kind of versioning so that only
new and updated words are actually update.

I'll go read up on file I/O. Thanks.

You have HOST SIMULATE and TARGET . HOST compiles in Forth on the host,
and you can use it to test your logic.

Yes.

SIMULATE compiles PIC code on the host.

So does TARGET. No need to differentiate between the two.

There's no particular reason to decompile the Forth code to
reconstitute your source and recompile it as PIC unless you really want
to.

I was initially thinking in a strictly interactive manner. Some
counsuling here has convinced me that the decompile/recompile route is
bad mojo. However I do want to ensure that the same source that's tested
on the host is the same source that's used to compile to the TARGET.

One way to ensure this and to facilitate longer term storage than
one session is to actually capture the text of the definition and save
it as part of the target environment. then it can be compiled for the
host, and the target, and saved to/reloaded from a file.

High level design changes before writing applications are a good thing.

Probably simpler just to recompile the source.

Right. But you need the source to do it. So even if you just noodling
around you need to squirrel the source away as you type it.

TARGET compiles on
the PIC and if you designed your simulator so it runs exactly the same
code that will run on the PIC then you might want to just dump that code
to the PIC to put it in flash.

Like I said SIMULATE/TARGET are the same.

' add2 picompile
' add4 picompile

Thanks for that too. The ' operates one word forward. Got it.

That's an early-intermediate application-code thing.

Still trying to get up to speed.

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.

Not standard. Got it. I'll figure out how gforth does it then.

You could try SEE SEE . You might get something by SEE WORDS too.

Led me to some more words. This line is abandoned as a bad idea. I can
capture text. EVALUATE can parse text. So SEE/WORDS and the like can be
left by the wayside.

Remember, your point in doing this is to decompile code so you can
recompile it. If you re-use the source code you can skip this whole
step.

Agreed. But I don't want the environment to devolve back to the
traditional EDIT/COMPILE/LOAD/EXECUTE model. If that were acceptable, I
could just use gforth/picforth model exactly the way it is now.

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.

Excellent. and I can use ! and @ to access that memory.

Yes, this is pretty basic application stuff.

Just double checking what I had read.

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.

I am certainly working on it. It's just that for the tasks that I need
to do, there isn't a generic book that describes it. I need the book
"Using Forth for Systems Programming."

I didn't think about this stuff being advanced topics, but I guess maybe
it is. So what you need is

parsing words
dictionary words
compiling words
data structures

These are likely to do most of what you want.

I've found gforth's reference chapter organized with these types of
words. Will read over the next few days.

Parsing words look ahead in the input buffer. PARSE WORD PARSE-WORD (or
PARSE-NAME ) SKIP will let you build most of what you'd want, if you
don't mind doing things one line at a time. You might find yourself
re-inventing standard words that you happen not to know the names of.

Dictionary words. FIND and SEARCH-WORDLIST find words. ' or ['] finds a
word but it bombs out if the word isn't there. Only use that when you
know for sure the word is defined. WORDLIST makes a new empty dictionary
you can add to. SET-CURRENT and GET-CURRENT deal with the default
dictionary. (Forthers call all the dictionaries together "the
dictionary" and call individual ones vocabularies or wordlists.)
GET-ORDER and SET-ORDER deal with which wordlists get searched by
default and in which order. MARKER lets you get rid of the latest
definitions.

compiling words. IMMEDIATE makes a word execute during compilation so it
will help the compiler do things instead of just get compiled itself.
DOES> is worth special attention. RECURSE Probably some other words I
DOES> haven't thought of would be extra useful.

Data structures. CREATE DOES> (You probably don't want ALLOCATE ).
HERE , C, ALLOT

I think if you figure out how to use these they'll give you most of the
tools you need to build whatever you want. Again, you might redesign
some wheels that are universally available, but if it's easier to
rewrite them than to find out about them then that's the way to go.

Excellent!!! I figured out how CREATE DOES> does it job. I'll read up on
the others after printing out this message.

Thanks so much 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
    ... testing words on the host, then transferring words to the target. ... where the students would be ultimately working with a cross-compiler, ... to a different compiler that will generate PIC code and download it. ...
    (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: IS this a proper way of freeing memory with free()
    ... but compiled with the host C++ compiler for testing in a ... system off the target. ... stunt with Perl on the target and COBOL on the simulator, ... Is there a common subset of Perl and COBOL? ...
    (comp.lang.c)
  • 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)