[Coco] Expert C programmer wanted

[Brett K Heath]

On Mon, 7 Feb 2005, John R. Hogerhuis wrote:

> On Mon, 2005-02-07 at 15:28 -0500, KnudsenMJ at aol.com wrote:
>
> > I was once interested in FORTH, and the 6809 actually seems to be designed
> > to run FORTH!  But this language is very weird, oriented towards small
> > projects, and expecting someone to learn it at this stage as a means to write  Coco
> > programs is just too much.
>
> Weird? I suppose. But easy to learn since it has almost no syntax.

RPN tends to throw people until they get used to it, OTOH once they do get
used to it they tend not to want to give it up (it saves typing amongst
other things).

> Small projects, small machines. Actually there's nothing in Forth which
> prevents it from being used on smaller projects.

It excels at getting the most from minimum resources, which makes it ideal
for embedded applications such as Open-Firmware, but it also has the chops
for larger jobs. The FedEx package tracking system is written in Forth (or
was as of a few years ago).

> In fact I think it is the ideal language for most 8-bit CPUs. At the
> point I outgrew BASIC, Forth *should* have been the logical step up
> before getting to C.

> As far as expecting anyone to learn it... well, I don't think learning
> something new would hurt that much. Besides that some of us old folks
> know it already... there are free versions for RS-DOS, OS-9, FLEX. It's
> part of the history of the coco just like other languages.

It's somewhat ironic that, AFAIK, there isn't a free version of Forth
available for the COCO. Forth is ideal for hackers as it let's you
directly manipulate the hardware from the command prompt, and the better
free versions (I'm thinking of f83 here) came not only with complete
source but also included "out of the box" a reasonably complete and
surprisingly comfortable development environment that was capable of
rebuilding the entire system from the provided source.

I mean, you had an interpreter, compiler, decompiler, assembler,
interactive debugger, cooperative multitasker and editor as well as a
nifty utility that would show you the source screens where a built in
command was defined, all running in a 24K footprint (counting buffers and
other system overhead). Add the ability to prototype and test both Forth
and assembly directly from the command prompt and the fact that the
assembler recognized inline structured conditionals (IF-ELSE-THEN and
BEGIN-WHILE-UNTIL) and converted them directly into the proper branch
commands (It's _amazing_ how much this does to clean up assembly
listings).

What's not to love?

[...]

> Anyway, anyone interested in Forth should check out the book I helped to
> republish, "Thinking Forth" by Leo Brodie
> http://thinking-forth.sourceforge.net and also try to get your hands on
> a copy of "Starting Forth" by the same author. These are a couple of my
> favorite programming books.

Got 'em both, and kudos for the republishing effort.

> > Better idea is just to write assembler, with a good macro processor and
> > stylistic guidelines and function-calling standards to keep the code from  turning
> > into spaghetti tangles.

> 6809 Camelforth comes with a built-in assembler so you can freely mix
> high level Forth and code words. So you don't really have to choose
> between the two. But I agree with the sentiment... 6809 assembly is an
> assembly programmer's dream.

Unfortunately CamelForth needs modification before it will run on a COCO
(not extensive modification, IIRC just the console and disk I/O). I've
modified (with permission) Brad's assembler to work with the target
compilation scheme of f83 and have actually ported almost all of f83
over to 6809 code, here's the inner interpreter and the low level for a
couple of defining words (indirect threaded, position independent). Before
you complain about the size of NEXT remember this is fully position
independent (the design goal is that it can move itself while running) and
look at how fast NEST and EXIT are:-)

  CODE  EXIT (S -- )
        S 2 , LEAS,
  LABEL >NEXT             \  Get [IP] and increment IP
        20 # PULS,        ( puls Y )
        Y X  TFR,         ( IP->X,Y )
        Y ,++ LDD,
        20 # PSHS,        ( pshs Y )  ( [IP]->D IP+2->IP )
  LABEL >NEXT1            \ [IP]+IP->X,D [[IP]+IP]+[IP]+IP->D,PC [IP]+IP+2->X
        X D, LEAX,
        X D  TFR,
        X ,++ ADDD,
        D PC  TFR,
  LABEL NEST
        X Y  TFR,
        >NEXT 4 + BRA,
         \ DODOES uses DOCREATE, and DOCREATE assumes that X contains the
         \ PFA of the word that NEXT just executed.
  LABEL DODOES
        20 # PULU, ( pulu Y )
        20 # PSHS, ( pshs Y )
  LABEL DOCREATE
        10 # PSHU, ( pshu X )
        >NEXT  BRA,
  CODE  UNNEST
   ' unnest   ' EXIT  @-T  OVER @-T  - SWAP !-T

For those few who care and are not familiar with forth; backslashes and
parens are used to mark comments, LABEL gives the current value of the PC
a name visible to the assembler but not the compiled system, CODE creates
a named dictionary entry in the target system. The stuff after UNNEST is
the target compiler calculating offsets so that when the CODE word UNNEST
is executed or compiled it transfers control to the EXIT entrypoint.

I'm right at the point where I'm ready to start cross-compiling images and
testing them on a target machine but have been stalled (forever!) by
communications difficulties between my plain ol cocos (a I and a II) and
my development environment (f83 running in dosemu under linux). Maybe
I'll take another look at the current batch of emulators to see if
they can help, or maybe I can shake enough cash loose to buy what I need
from Cloud-9 (I think they have what I need).

> Also, there is a lot of freely available Forth code out there on the web
> which could be used with coco. There are a lot of historical variants of
> Forth, so there would be tweaking here and there. Forth is a
> semi-compiled/interpreted language so the trend at the time was to
> publish your source, sort of like happened with BASIC programs.

I've always thought of FIG as one of the roots of the open source
movement, and Laxen & Perry's "No visible support software" is certainly
in the same spirit. "Here's the program, here's the source,
do with it what you will as long as you give us credit for our work".

Ok, that's enough raving for now.

Brett K. Heath