FORTH

[tom cloud]

On August 19, Darrell Norquay <dnorquay at awinc.com> wrote:

I've been thinking about learning FORTH for a long time, but that's as far
as it ever got.  There is a company called New Micros Inc. who specialize in
FORTH embedded systems.  They have compilers for all the 68HC*** processors,
and possibly more as well.  I don't have the address here, but I can dig it
up if you want...

regards
dn
dnorquay at awinc.com

============================================================

Don't know if anyone cares, but I was looking through some old postings
and saw what dave wrote to me (above).  So, here are some musings
about FORTH.

FORTH 'should' be as portable as 'C'.  It 'should' be higher level,
yet still allowing in-line assembly code where needed.  It's fast,
very compact.  It allows 're-defining' functions on the fly.  It
is both an interpreter and a compiler (sorta like BASIC, except with
BASIC you gotta buy the compiler and usually get stuck with someone's
crummy run-time module -- or worse, P-code).  I'd hope one could get
an easily ROM-able product now, don't know.

Basic concept:  one writes a 'kernel' in the code of the particular
processor.  Then 'words' (or definitions of functions) are written
using the basic functions of the kernel (spec. OR, AND, NOT, +, -,
*, /, ^, SHIFT, ROTATE, etc).  It's been probably 12 years since I've
used it, so my bremembrance ain't so good.  The neat thing to me was

 -- it could be used in an interpreter mode -- at any level of
    development (i.e., could 'compile' definitions to a certain
    level and then 'play' with it in interpretive mode)

 -- Each 'word' could have meaning (e.g. 'LIGHT_OFF', or 'INJ_PULSE')
    and, of course, parameters could be passed to it either on
    a stack or from a memory variable (the version I used could not
    implement a table, so had to load variables from a 'word').

 -- as opposed to 'C', it uses 'real' words (ex. 'NOT' rather than '!'),
    not weird programmereze.

 -- and there's other reasons I liked it, I think (there's two things that
    go first as you get older, I just can't remember either of them
    at the moment).

The main reasons I didn't like it:

 -- No one made a product (I used a Z-80 product called StackWorks Forth)
    that really worked like I wanted.  Seems many are stuck in what
    I call the 'Pascal' mode.  I.E.:  By God we're gonna force you
    to write structured code or abide by some other stupid rule.
    [To my notion, if I want to use my     damned screwdriver as a
    chisel, I will!!  And if I want to JUMP or GOTO, I will.  Hell,
    if I want to execute a GOSUB without a RET, I will!!]  ((Where's
    the fun if you can't execute multiple branches from 'variable'
    jump tables so that even you can't figure out why or where you
    are??))  I guess if it ain't the BATF, it's the dreaded Software
    Police.

 -- Secondly (if that's a real word), FORTH code is known as
    "write-only-code".  You'd better document carefully, because
    even you won't be able to figure out what you did after the
    program gets large and some time goes by.  (Sure, INJ_ON
    takes a parameter from the stack, signifying time in mS, and
    pulses the injector ON for that long, but how does it really
    do it -- and if you change one of the lower order definitions
    will it affect INJ_ON?  It's 'threaded' code, which
    explains how it can do so much in so small a space, but the
    threads can get real convoluted and, if you're not careful,
    'upgrades' can be deadly.)

Oh well, just stirring the cauldron.
tom cloud