Re: New Linux 4word

A few thoughts....

> Nobody seems to document what version of Chuck they are based on,
> or what they have accomplished. People seem to work on newer
> version sent to them by Chuck and seem not to publish those
> original versions or diffs, only their own hacks.

I get new okad2 releases from Chuck regularly, but the
colorforth object boot code hasn't changed for a very
long time and is the version linked via Chuck's and my
web sites.  He has modified the cf code compiled by the
boot image, but not modified the boot image.

He has coded stuff like the USB Flash support code as
cf code that gets compiled by he hasn't replaced the
object code.  Most recently he has  been looking into
making a version that boots from a hard disk partition.

Just last week I herd him talking about putting together
a new release that wouldn't be based on the boot code
written in assembler that has been in use for a couple
of years.  This would have a small kernel, maybe 1K,
that compiled cf code, and factor the editor into one
of the source programs that gets compiled at boot,
and the kernel itself will be recompilable from cf source.

> Actually, I think that very little is accomplished. There is still no
> colorforth that boots from virtually any PC.

There are stand alone versions with a pretty broad range, and between
the many DOS/WINDOWS/Linux versions many PC platforms are covered.
But cf was never intended to be something to run on virtually any
PC, that involves providing drivers for thousands of different
hardware options.  That was never the idea here.

> That is the most
> important accomplishment that counts in my book. Another mile stone
> would be an official glossary, where everybody documents her
> deviations from the glossary.

Glossaries are nice.  I haven't published the glossary that I got
from Chuck a couple of years ago.  It is not a complete document
however allbeit a nice starting point.

> What seems a bizarre starting point isn't. There is a smooth sailing
> path from a Forth defined in Forth assembler to a Forth in Forth.
> You may not realize that the scripting of ciasdis extracts names
> from binaries.
>
> Then I'm skeptical of the whole Metaforth stuff. I have seen so
> many terribly complicated idiosyncratic versions of them.

Sure, most metacompilation is rather complicated idiosyncratic
stuff.  But it is important to remember that Chuck's approach
to metacompilation is substantially different than that used
in more common metacompilers.  Other people love complicated
source with as many requirements of the metacompiler to
achieve 'portability.'  This means that they have to support
every complicated feature in their Forth, squared, to do
metacompilation of sources that require all those features.
And doing it all 'portably' means that it is a very good
example of how other Forth programmers make that job a hundred
times more complicated than Chuck will make it.

For instance Chuck will focus on what is need to metacompile
his kernel without worrying about compiling all the applications
as part of the metacompile, and without worrying about name
conflicts with all applications in the process.  Chuck focues
on compiling his kernel not every possible 'portable' Forth
source kernel in the world.  So natually his metacompilers
tend to be a hundred times less complicated than the garden
variety metacompilers that frighten people.

But this is true generically of his Forth.  Most Forths are
full of frightening complexity compared to how Chuck implements
Forth, and many people don't bother to study Chuck's style because
they are turned off by the terribly complicated Forth that they
see other people doing.  Yet the people who do these type Forths
see them as not being overly complicated because they see them'
as less complicated that the conventional environments that they
are used to.

Meta compilation is a good example of something that can be
terribly simple or terribly complicated, depending on style
and approach.  It seems a shame if people reject Chuck's
simple style as too complicated because they have seen so
many other people with overly complicated metaocompilation
style.

I started with metacompilers written by other people, ones
that came with 500 page manuals.  I have seen and used metacompilers
written by for standard Forths, and written them myself.  I was
pleased to see how Chuck did the first machineForth cross compiler in
300 bytes of object code.  I feel sorry for anyone who rejects the
idea of understanding how simple it can be because most people
prefer to make it complicated.

> I want to start from assembler, then add maybe macro's for headers.
> If that can be improved, fine. Probably it can't.

Chuck has said that he will do a kernel in cf rather than have
to start with assembler source.  Once you have bootstrapped a
kernel from assembler, and then written a system in Forth, you
can complete the loop by writing version completely in Forth.
But you have to bootstrap first.

The fact that Chuck has been working with cf, doing productive
CAD work, is a sign the system has been working well in its
original environment.  That has has priority over making a
nicer version of cf in cf.  But Chuck has said that he will
make a version that isn't based on an assembler kernel.

> An assembler is the proper starting point. There is no Metacompiler
> without assembler. And an assembler may be enough.
> Unless of course you think you have a nice source if it is sprinkled
> with
>         cd45 2,      12 1, 3135 2,

I heard Chuck talking about this a couple of days ago.  He said that
he had always written a target assembler in Forth because it only
took a block or two in most cases. Then he would write the assembler
portion of CODE words or a kernel using the assembler so that it
would provide more meaningful code representation to the programmer.

He said that the Pentium assembler was such a mess, and so complex,
and that he used so few of the Pentium instructions anyway that it
just worth the effort to provide a full high level Pentium assembler
for his needs in colorforth.   He added that there were so many
instructions and address modes etc. that people would need to have
a book in front of them anyway to look up opcodes to see what they
actually did.  So given that he needed only a few Pentium codes,
and assuming that most readers haven't memorized the entire Pentium
instruction set, or that the variation of the syntax that Chuck
would use in a RPN assembler would be completely obvious to readers
he didn't add a layer of Pentium opcode names.  He said, you are
going to have to go look them up anyway to understand that level
of the programming.

He added that after bootstrapping then he was in a position to
do the normal thing of coding a Forth version that won't need
a kernel in assembler to get going.  It was just a matter of
priorities.

I think the fact that Chuck has mostly been focused on using
colorforth, and reports that he finds it very useful is an
indication that it has been a successful experiment.  He
reports that he finds it a very very nice Forth.   And his
focus has been on using it as a tool, not making it the
focus of a product.  He gave it away instead of making it
into a product to sell.   His focus has been on using it
and at some time he will have another release.  We thought
it was going to be a USB Flash hosted version, but now it
appears that the next version may be hard disk hosted.

This will also open the door to others who want to replace
the floppy or hard disk boot with CD boot or USB boot or
whatever and the door for people who prefer to work with
a version that metacompiles from Forth source rather than
the old bootstrap versions that booted from a package
written in assembler.

Best Wishes