Re: Holy Doodle Batman

["John Drake" <drake@xxxxxxxxxxx>]

-----Original Message-----
From: Jeff Fox <theFox@ultratechnology.com>
To: MISC@pisa.rockefeller.edu <MISC@pisa.rockefeller.edu>
Date: Monday, July 05, 1999 8:25 PM
Subject: Holy Doodle Batman

>I learned a lot from ShBoom.  I got the programming manual and studied
>it and discussed the ideas with Chuck a lot, but hey that was that was
>ten years ago!
>
>I think I would summarize the recent discussions as saying that the
>options we have today are:
>
>1. work the common RISC or CISC chips
>2. work with fifteen year old Forth chips although they are getting hard to
find
>   (Novix, RTX etc)  (sc32 is in between)
>3. work with ten year old Forth chips recently released
>   (Shboom)
>4. work with your own versions of the old designs like the Novix from
Russia,
>   or the Novix in FPGA in Sweden, QS-5 or P16 in FPGA etc.
>5. work with Chuck's vlsi chips from 5 years ago (P21)
>6. work with Chuck's latest vlsi designs
>7. work out your own new designs in FPGA or VLSI

Well for me 3, 4 and 6 seem like the most viable options.  I know that
you, Chuck and others find the 20 bit wordsize a "non-issue", but for
the project I've been thinking about (DES codebreaker) wordsize is
an issue.  My code keeps the 64 bit key and data values in 4
consecutive 32 bit words on the stack.  I suppose I could use the
C programming style found in "Numerical recipies" and store each
bit in a seperate word, but that just seems wasteful to me.

>If you need more documentation to get started you might want older
>things that have had more time to be documented.  If you want to be
>out in front then hopefully you will write some documentation for those
>who may also want to move to more modern designs.
>
>There may be other options that I have not listed.  As for ShBoom I must
>admit that I haven't followed all the changes made to ShBoom since it was
>taken from Chuck in 1988 or 89.  I know one of the designers claims that
>in order to make ShBoom II more attractive to Java and "C" programmers
>that some of the operations that are important to Forth were degraded.
>In a  way it is a little like what was done to Forth in ANS Forth.

Well I wonder how much actual degredation was done?  The PSC1000
still seems quite fast for Forth operations.  If the claims about C and
specifically Java speeds are true, then perhaps it was a good trade-off.
Marketting it as a Java chip has brought 'economy of scale' to PSC.
And, for better or for worse, Java is an important feature for web-devices.
(Donning my flame resistant suit.)  As a consumer I'd be willing to pay
a little (though not a lot) more for Java functionality in certain web
devices.  In a cell-phone, I probably wouldn't care.  In a set-top box
I would.

And what operations in ANS Forth were "degraded" as in respect to
other Forth's like Forth-83 or figForth?

Honestly, what I got out of what Chuck recently said about ANS Forth
wasn't so much things left out as it was things that he didn't like being
put in.  I can't see how someone can say they hate ANS Forth, but like
Forth-83 since the two are so similair (and I know that you didn't say
that Jeff.)  Chuck also felt that ANS Forth was missing out on some
good innovation like @+ which could help write faster code without
needing super-optimizers.  And he didn't like the way the document
read, but that's more of a technical writing issue than a standards
issue.

I think the ANS standards committe could easily accommodate all
of Chuck's recommendations by :

1) Creating a minimal "Inner-core" wordset that consisted only of
words that were likely to be primitives (leaving out I/O, compiling,
double-words ect.)  It would be nice (though not necessary) if
all "outer-core" words could be created directly from the
"inner-core" words.

2) Adding supplimental ANS Forth documentation that covered
everything in a more "reader friendly" way.  (Some people are
already working on this.)

3) Add an optional wordset that would allow people to experiment
with more VM options and optimizations.

This last one is a bit hazy.  You could operations like @+ on top
of ANS Forth provided that you created an "address-register"
variable.  Of course that wouldn't be as having a physical register,
but it could offer some speed-up.  It's at least worth investigating
(to me anyway).