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

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.

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.

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 . When you compile a command, you make a definition
on the host that returns that address. You also make a second definition
that puts PIC code on the host for the simulator to execute. Whenever
you compile more code into the simulated definition, you increment the
variable to remind you about the PIC memory you're using up.

So you can compile source code, and each word tells you the PIC address.
Making the call to that address and writing the code to the end of the
current definition ought to be easy.

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

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.

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. SIMULATE compiles PIC code on the
host. There's no particular reason to decompile the Forth code to
reconstitute your source and recompile it as PIC unless you really want
to. Probably simpler just to recompile the source. 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.

' add2 picompile
' add4 picompile

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

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

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.

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.

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.

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.

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

Relevant Pages

  • 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: Build your own Forth for Microchip PIC: Design thoughts
    ... the host, then cross compile the word into its PIC equivalent for ... manually specify which words to transfer to the target. ... FOO and you add a name FOO to the host dictionary, ... suggest you avoid multi-pass evaluation for your special PIC compiler. ...
    (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: Check the linux type?
    ... that the host where the compiler will run is running SuSE ... compiling a binary for your 386 on your PPro because it's faster. ... Only people with severe mental problems think configure scripts are ...
    (alt.os.linux)
  • Re: "no variable or argument declarations are necessary."
    ... a new crater on Mars, named after the NASA employee who thought the compiler would catch errors. ... Add to this explicit name-object locking to implement constants and I think you would have most of the features you want. ... Since names are stored in dictionaries, a dictionary attribute to disallow/allow new keys, and a way to set individual elements in a dictionary to read only would be needed. ... An external checker could possibly work as well if a suitable marker is used such as a bare string. ...
    (comp.lang.python)