Re: Color Forth 2000 from a FIG FORTH FAN.
Hi Ben and other MISC readers,
Ben Franchuk wrote:
>
> Jeff Fox wrote:
> >
> > Dear MISC readers:
> >
> > Chuck Moore gave an interesting presentation yesterday
> > to the Silicon Valley Chapter of the Forth Interest Group
> > on his Color Forth 2000.
>
> As a person who has been following Forth since FIG FORTH
> on the 8080 off and on I wonder if Forth and Forth style
> languages have really been improving. All the improvements
> since then seem to be a step backwards.
It is good to question things. My opinion is that
Forth has been taken in a hundred different directions
by a hundred different people. It is very hard to say
much about all the directions since there are many examples
of people going in quite opposite directions.
If you think North is bad, there are people headed South.
If you think West is bad, there are people headd East.
I often complain that people refer to Forth as if everyone
was doing it the same way and trying to go in the same
direction.
> Meta-compiling is
> great if you have a working copy of Forth,but I still like
> a good old assembly listing because with good comments as one
> can port the code to many different machines.(Some versions
> of FIG FORTH could be got for a low $ cost.
> something handy for people on a low income like myself)
I went from assembler to Forth source for two reasons,
the first was I found the source much easier to read.
The second was that the metacompiler I wrote would compile
in a few seconds and I was sick and tired of waiting for
an hour or an hour and a half for MASM to assemble a
Forth. A few seconds made my life a lot easier. Also
every version of MASM did different things with macros
and made things a lot of work.
But I also maintain that the original document on Forth
stated that Forth was written in Forth and that this
was one of the things it was very good for. I couldn't
agree more and don't see that his ever changed except
for the people who tried to write their Forth in assembler
or 'C' or Java or Cobol or whatever.
> Can you get Color Forth 2000 for hardware
> that is not a dedicated machine. What if I wanted to
Color Forth has not been released. The only way to "get"
it would be to implement one yourself. Chuck would
encourage people to try it and experiment since it isn't
hard to do.
> run a dedicated controller using the rabbit CPU,tiny keyboard
> and and a 320x200 LCD B&W screen. Can I still port Color Forth?
> or is it tied to just one configuration.
The concept is as portable as any other Forth. If a machine
had only B/W display then different fonts and font attributes
could easily do the same thing as what Chuck is doing with
Color. In this sense it is a type of visual Forth. If you
have a machine with color but you are color blind you have
the same problem.
Just because only version has been implemented does not
mean that it is "tied" to anything. Because the concepts
are quite portable I have made an effort to provide the
information about it to a wider audience than the 25
people at the SVFIG meeting.
> > Although I have had many years of working with Machine Forth
> > and understand the stuff that came from Machine Forth
> > Chuck has dropped many of the odd things in Machine Forth
> > and returned to more traditional ways of doing these
> > things. He has also introduced other new wierd stuff.
> > He is still using the A register concept and he still
> > uses "-" to specify one-complement as he did in
> > Machine Forth.
>
> The A register wow! - Forth has discovered auto incrementing pointers.
> Hmm have you heard of INDEX Registers yet?
Yes, believe it or not. Both Chuck and I have heard of Index
registers. ;-) Chuck has explained why he split the @ and !
atoms into smaller particles to introduce ways to optimize
things on a simple machine. He felt that it should have
been in ANS Forth, but I doubt if anyone ever lobbied for
it.
> This still indicates a weak problem with Forth. The primitives
> to place information off and onto the the stack is still limited
> as use of Forth's language style is limits you to simple
> absolute primitives.
> foo->bar in a language like C has to still broken down I believe
> into var foo : bar 5 ; ... foo @ bar +
Forth isn't 'C' and 'C' isn't Forth. I am happy with that.
I know other people would like to see Forth become 'C', not me.
> > But IF does a DROP like traditional
> > Forth and there is no -IF (IF CARRY) as there is
> > in Machine Forth.
> I think IF not dropping and ! with the arguments reversed is a better standard
> since this makes direct coding a bit cleaner.Why not DIF for drop IF and IF not
> dropping. The carry status is real handy thing to have.
I found the carry bit implementation to be interesting and liked
using both IF and -IF. Chuck found it less useful and dropped it.
I think whether IF drops is pretty much a wash. There are things
about it that are nice about both versions. One solution would
be to offer both in the instruction set. But one should
remember that there are also tradeoffs involved in hardware.
The number of instructions is limited. I spend many years
benchmarking the results of small changes to the instruction
set. It is hard to just guess whether an extra IF would
be more valuable than something else. It really is dependent
on the application. If you know the app and you know it
does FOO quite often perhaps FOO would be a more useful opcode.
About all you can do simulate an instruction set and compiler
and application and compare it to a variation.
> > Color Forth still uses colors instead of a lot of
> > the words in traditional Forth. Chuck has changed
> > some of the colors he is using.
> >
> > Color Forth now has a more complicated method of
> > packing (preprocessing) source code. This makes
> > for a much more complicated editor and a somewhat
> > more complicated compiler, and it was done to
> > get about a 2x speedup in the compiler. The
> > source code is packed into 32 bit words using
> > a Huffman encoded scheme.
>
> YUCK ... What ever happened to ASCII?
Nothing. Most people still use ASCII. The reason most
people use ASCII is that they need to be compatible with
other programs that use ASCII. Chuck has worked almost
exclusively with his CAD program for ten years and he
has his own editor in the CAD system so he doesn't
have a requirement that the source be editable with
Emacs like many other people.
Color Forth is certainly not tied to CAD, Chuck's
CAD font, or to ASCII. Since Chuck has been using
his own character set in OKAD he has had no need
to bother supporting ASCII, just extra work with
no useful benefit.
The way he respresents his source code has changed
to his new system of packed preprocessed 32 bit
words because that is the way he processes CAD
information in his tile representation. He explained
the many reasons he did it this way, most of them
have to do with making things faster. Anyway the
CAD program is not byte oriented and ASCII is.
> Can't you have Forth regenerate itself into a loadable
> format and load that.
Of course one can.
> I think that the absolute jumps
> and calls in Forth Hardware is a Bad design even if it saves
> a few nanoseconds.
The issue is hardware design more than software. You have
a right to your opinion. What alternative would you prefer?
How would it effect the hardware implementation and speed?
> > The compiler still benefits from the Color Forth
> > approach by the preprocessed source and color
> > tokens identifying what type of quantity is
> > about to be compiled. It appeared to me that
> > there are interpreter and compiler wordlists
> > like in cmForth for increased speed and
> > simplicity. Numbers are already in binary
> > form from what I could tell. This means that
> > the compiler does not search through the whole
> > list of Forth words and then upon failing
> > try to convert a string into a number in the
> > current number base. Instead there is no
> > dictionary lookup (let alone one that must
> > go through the whole dictionary each time)
> > or conversion for numbers so the compilation
> > is very fast.
>
> Sounds like tokenized BASIC.
I thought his packed source looked like compiled
Forth to me. But I can see the resemblance to
tokenized source as well.
> > Chuck has said that it is interesting that
> > traditionally Forth has been used on resource
> > starved systems and that Color Forth is
> > designed for a resource rich system. So
> > instead of trying to optimize for small size
> > he actually tried to use as much as he could
> > force himself to use. The compiler is still
> > about 1K and remains resident in memory.
> > Since compiles are instantaneous Chuck
> > intends to keep things in source and compile
> > them when needed. Source and object code
> > are about the same size.
>
> I think you need to have resource limits.
Everyone does. I have yet to see any system that
did not have limited resources. Nobody has infinite
speed or infinite memory or infinite instructions etc.
> Is this due to a better design or just faster
> hardware.?
Both. Faster hardware. Blocks already in memory so
the disk doesn't slow things down. Faster reading
of source, no need to search dictionaries for numbers,
smaller dictionaries with fewer words to search,
separate interpreters and compiles invoked by
different color tokens all make the system faster
than traditional techniques used in Forth.
> > He is using his ATI graphics card to do the
> > work of displaying. He says it was more work
> > than it would have been to write code and just
> > do it in software, but it does take advantage
> > of the hardware that is there. He is working
> > in 1024x768 mode with a display routine as
> > a background task with 5 to 30 screen redraws
> > per second. He is still using large characters
> > and has 40x25 on the screen in a block. Blocks
> > are 1K bytes, 256 32 bit words. It is a word
> > addressing system which is a close match to
> > his Forth chips and bytes are not important
> > for his OKAD work.
> >
>
> That just proves to me HI-RES is not what is cracked
> up to be. 40x25 sounds like TV resolution. I say
> forgo the hi-res stuff and just have the video
> display ani-alias the text in low res.
The main purpose of the system is to display, edit,
and simulate chips being designed. This is graphic
in nature not possible in low res text. Chuck has
rather weak vision and needs to make the characters
large enough to read without eye strain. He can
zooms way in when editing the chip layout.
He uses the video card hardware to do the bit block
transfers in hardware instead of software. I like the
fact that screen refreshed take a fraction of second.
I have seen other software take forever to redraw
a screen with complexity of his cad displays. And
some software takes forever to display anything. ;-)
> > He is booting from the boot sector on the floppy
> > in protected mode with access to the full memory.
> > The boot sector also contains the floopy driver.
> > He is just reading and writing complete tracks on
> > the diskette. Later he will provide a hard disk
> > driver that he will need for the OKAD port.
> >
> > He has technical docs for the sound card and
> > network card and will add drivers in the future
> > to use these in his Color Forth.
>
> I still think Forth needs a regular file
> system.The screen idea I never did like other
> than it made for simple line editor.
But Blocks predated file systems in Forth. They are
one of the "changes" that people have made to Forth.
I thought you said you felt that the changes since
FIG Forth were bad things. FIG Forth used blocks
although I adapted one version I was using to use
native OS files.
I know most people have abandoned using blocks
for anything even when they are far superior
to files, because people want to use Forth with
other programs that use files.
There are certainly times when you need files.
OKAD has to generate chip layout files but it
doesn't need to keep source in files because
they are not being shared with anything else
in Chuck's system. He feels it is important to
solve the problem you need to solve and not spend
time doing things that are not really needed.
He simply doesn't need source in files in OKAD
and he made his Color Forth much faster by not
putting source in files. He has also always
maintained that blocks help factor things into
smaller pieces because it is harder to let
them run on and on for pages like some people
do in files. That doesn't mean that he thinks
(or anyone things) that no one needs to use
files for anything.
> As a side note I think most programs are
> extra big because the don't have standard
> interface for text and graphics.
That was suppose to be one of the benefits of Windows.
Because the text and graphics and the rest of the user
interface was going to be in one place instead of in
every program the system and the programs were suppose
to get smaller.... Just the opposite happened of course
and things really bloated up because of the way it
was implemented.
> I would
> like to see a 16 bit text display.
> [color-3 bits][GUI text style-5 bits][8 bit char]
That sounds pretty easy and nice. It reminds me of the
GUI I did for iTV.
> If done right the hardware will ani-alias text
> and scale up for larger displays.
> A graphics display will be UNDER the text display
> making menus easy and fast.
>
> <mouse/cursor>
> <menu layer>
> <text layer>
> <graphics layer>
Sounds interesting, Color Forth sort of works that way. If
I do a complete transcription of the presentation you will
see what I mean about cursor, menus, text, and graphics
in this Color Forth.
> > in his Color Forth and says he is having a
> > lot of fun doing it. He said, Forth is a game,
> > life is a game, and it should be fun.
>
> That is a good idea there, that computers make life easy
> and fun for people.
I agree that it should be fun. I hope other people get
to have fun with what they do with computers. I know
that it isn't much fun for some people.
Jeff Fox
