Re: Build your own Forth for Microchip PIC: the nature of metacompilation

In article <139i7v6mnu2t4bd@xxxxxxxxxxxxxxxxxx>,
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote:
none Byron Jeff wrote:
...
I'm not getting a clear sense of what modern forth development models
are. Do forthwrites typically develop interactively using the forth
interpreter or is it really a true edit with an external editor,
load/compile via include, then restest? I want to avoid the latter.

It sounds as though you're trying to do away with source in order to
further your interactive development model.

That's not exactly it. I really want to integrate the source into the
interactive development model.

IMO that's throwing the
baby out with the bathwater. Source is useful, because it's able to
capture information that cannot realistically be kept in your executable
object (even the host version). Most critically, source contains
*comments* that explain what your code is doing, why it's doing it that
way, how to use various definitions, and (most important) stack comments
for each definition.

No doubt. I'm just not understanding why after all of the years of forth
development, that an integrated editor for source never emerged? Forth
clearly started as an interactive system. While it retains some of those
interactive elements, the prevailing mindset seems to be usage as a
compiler with the source edited offline.

A Forth development model is really a hybrid: you do write code using
either a Forth-resident or external editor.

Forth resident editor seems to be very system specific. Here's what
gforth's manual had to say on the subject of editing forth source:

http://www.delorie.com/gnu/docs/gforth/gforth_59.html
---------------------
If you have tried out the examples in this section, you will probably
have typed them in by hand; when you leave Gforth, your definitions will
be lost. You can avoid this by using a text editor to enter Forth source
code into a file, and then loading code from the file using include (see
section 5.16.1 Forth source files). A Forth source file is processed by
the text interpreter, just as though you had typed it in by hand(7).

Gforth also supports the traditional Forth alternative to using text
files for program entry (see section 5.17 Blocks).
---------------------

While I completely understand why external editors are useful (I'm a vi
guy myself) and completely agree with the freedom that it provides
different users, it would still be useful to be able to function within
the Forth environment proper.

GForth is quite helpful in a couple of respects here. First it does
integrate the readline line editing capability into its command line.
Second it keeps a history file of previous commands entered. The two
facilities are quite close to being enough to a working integrated
editing system.

It's really easier to think
through your logic when you're working with a related group of
definitions in a file. But that doesn't lock you in to testing huge
code batches.

No real argument with this. Just wondering why it has to be an external
editor.

You've spent a lot of time explaning to me the transparancy aspect of
Forth cross compilers. I'm just trying to figure out why that
transparancy doesn't extend to editing systems.

The first step is to develop a working kernel that will include
necessary primitives and support for your XTL.

I've made progress here implementing and testing a few primitives
(pushnum, add, drop). I realized early on that keeping the TOS in a
register isn't a win on the PIC. I'm implementing the stack using the
PIC's only indirect register pair.

That pretty much needs
to be a downloadable or flashable image generated from a (short) list of
files.

While I see the utility of writing a Forth based assembler for the PIC,
I'm simply using my existing assembler to write the XTL.

Subsequently, you can write definitions in your editor and test them
individually by doing a copy/paste into the development window of your
Forth, whereupon they're compiled & downloaded to your target for
testing.

This saves re-typing and preserves your source along with its
vital comments.

But why isn't there an integrated source editor generally available?
Especially something that's smart enough to know what definitions have
actually been changed and need to be recompiled?

I know it's broad, but I'm curious as to why development gravitated to
the separate editor along with the Forth interpreter.

I got from my reading that older self hosted Forths implemented file
blocks and that file block editors were integrated into the self hosted
system. Once the migration to implement Forths on top of existing OS
started, why didn't a native integrated file editor emerge?

Incidentally, the time to write your comments is when you're writing the
code, not after the fact.

Absolutely. In my assembly code I generally put a header comment on
every routine and comment any code that isn't self documented.

You write what this definition will do and
how it's intended to be used, then its name, and its stack comment.
This is then in front of you as you work out the actual code. If you
realize that something is awkward (e.g. you need your stack arguments in
a different order) you immediately change the comment. This way you
have much less to juggle in your head. Newbies often find it helpful to
have stack comments interspersed in the definition, not just at the
beginning.

All good ideas.

I guess the reason that I'm harping a bit on development style and
integrated editing is the fact that if I keep all of my level
definitions in a file and recompile each time I make a change, I'm going
to have to track revisions that need to be downloaded to the target
anyway. It's important to me because I'm not operating on a RAM based
target system where rewrites are effortless. Flash is slow to write and
has limited write cycles (only 1000 writes/cell guaranteed across the
temp range for the PIC though the typical expectancy at 25C is 100,000
writes).

If the definitions are in an external file, then loading that file means
recompiling everything. Now that in itself isn't too problematic. But
tracking actual definition changes is.

It would be easier to track such changes when editing the source. But
with the typical development model of editing externally, there's no
transparent way I can see to track version definitions short of
compiling the definition and then hashing the result, while keeping the
current hash value of that definition on flash elsewhere. Any
definitions that are missing or have a different hash value would need
to be rewritten to flash.

I was thinking I could integrate such version tracking in a resident
Forth editor for the source. When I change a line, only that line needs
to be recompiled and version tracked. In short it's a visual view of the
existing Forth command line system.

As for keeping comments, that was one reason that I wanted to store
target definitions in string format. The other is to have the definition
available for compilation to both the target and the host. I realize the
error of my initial thought of recompiling the host version of a
definition directly to the target. But having a string version of the
source and compiling for both is a possibility.

Assuming you successfully test a bunch of definitions in a session, you
then add that file to the list of those that generate your kernel for
the next session. Thus, you always start a session with a kernel that
includes your tested code thus far, and can go on from there.

But that's right back to batch development. That means you've thown out
my baby (small incremental development flashing only changes) with the
bathwater of using the external editor in a standard
edit/compile/download/execute system.

There is a hybrid model between the two extremes of executable code only
and externally filed code only. Source stored as text in forth (read and
written to files between sessions of course) with incremental
compilation and download is that hybrid.

I'm trying to figure out how to edit natively in Forth in that hybrid.

Does this help?

Some. Thanks for the input.

BAJ
.

Relevant Pages

  • Re: science writing/editing/publishing/journalism
    ... The best money for an editor, in my experience, ... >Bob has already pointed out that you are considering more than editing. ... The editors of medical journals tend to be rather better qualified ... > Government jobs tend to ...
    (misc.writing)
  • Semi-OT, but only semi: Blue Pencil Essential
    ... Once they were key figures in literary publishing, respected by writers ... process between author and editor no longer exists in Britain. ... But if I did need editing, ... contemporary publisher would call "fuck-off long". ...
    (sci.electronics.design)
  • Re: text editing in ubuntu
    ... i love linux and i've always wanted to ditch windows completely ... never found a satisfactoty means of editing text, ... i also need a good html editor. ... Acer Aspire 7520 with Jaunty Ubuntu. ...
    (Ubuntu)
  • Re: redhat 9 text editor
    ... Are you saying you need a text editor or a web WYSIWYG editing tool (a'la ... As a GUI for web editing and all forms of scripting (PHP, perl, whatever) ... Apache is a web server. ...
    (comp.os.linux.setup)
  • Re: Mail - dumbed down to the point of pointless
    ... You can force any file to open in the text editor of your ... It's rare on most platforms for anyone to be editing code...! ... Text Wrangler does that, at least for HTML, ... If you save the file it has the TW icon, so obviously when you click on it ...
    (uk.comp.sys.mac)