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

In article <1386p75reqrcad4@xxxxxxxxxxxxxxxxxx>,
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote:
none Byron Jeff wrote:
Hi folks,

I'm back for another round after thinking about it a couple of days. I'm
coming to the stark realization that I'm really a Forth novice. My lack
of Forth experience seems to have two spheres of influence:
...

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.

Questions:

1. Instead of taking input from the normal input buffer, I want to
fundamentally parse a dictionary definition. The way I see it is
something like running "see <word>" taking the output and parsing it.
What I'm out of the loop with is accessing dictionary definitions
directly and parsing the words in those definitions.

2. I know that create puts new words in the dictionary and allot will
allocate space. I'm unsure how to access that allotted space once I
created it or exactly how to get a pointer to the definition's alloted
area. Brad used C, to extend and write into the dictionary space for
example.

3. I used strings above due to ignorance. How could one simplify the
examples to

add2 picompile
add2 picload

for example?

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 believe I have good reasons to explore an alternate model of testing
words on the host before transferring to the target. It fits my existing
embedded systems development model. Frank Buss in the other reply
validated it by pointing out that testing in a emulator would be a good
idea.

I'm trying to find ways to adapt forth to the environment that I have
instead of adapting the environment to fit forth's expectations. I'm
just trying to do some quality control in the design stages to ensure
that adaptation is done in a forth-like way.

4. I know that Forth parses and does dictionary lookups. What kinds of
words should I be looking for to do these activities? Can parsing be
done from an arbitrary buffer?

Ideally it should replicate the resident system, but generate PIC code
and download it transparently.

See above.

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.

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.

The transparency I'd really be interested in moving forward is the
automatic transferrance of yet to be compiled words. For example say we
created and tested the following definitions on the host:

: 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

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.

I'm sure I have more, but I think this is enough to motivate some
discussion on the subject. Am I thinking about the problem in terms that
are even remotely Forthlike? Or would another approach make more sense.

Thanks for any thoughts on the matter,

You haven't read the XC standard docs yet, have you?

I read some. Doesn't seem to fit my particular requirements. If I really
wanted the follow the standard, I should follow your suggestions at the
top of this post.

To reiterate my questions:

1. Words for accessing dictionary definitions like SEE does?
2. Parsing from somewhere other than the input buffer. Or alternatively
how to transfer text into the input buffer without typing it?
3. words to address allotted memory in the dictionary?

Thanks,

BAJ
.

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 (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: Strange pings from 127.0.0.1
    ... I'll look into seeing if I can't trace down the infected device by assuming any target host is not the source. ... it might be that you have someone on your network ... >> Ethical Hacking at the InfoSec Institute. ...
    (Security-Basics)
  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... Because if you're doing tokens, wouldn't your token tables go in data space, with your token interpreter and primitives in code space? ... Compile words for target substituting local I/O access for remote ones. ... You can't, for example, test any of your PIC code on the host. ...
    (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)