Re: [SeattleRobotics] Re: Forth for Robots (from Loki's first steps)
- View SourceOn Fri, 01 Feb 2008 07:55:32 -0000, "David Wyland" <dcwyland@...>
> Almost all the other languages use equations: C=A+B. We learned thisSmalltalk has the same feature, although it gets this by way of the garbage
> in algebra and it is the first thing you learn in all the Fortran
> derivatives, such as C, Basic, Pascal, Python, etc. However, C=A+B
> implies *named* variables A, B and C. So we *generate* named variables
> and then have to keep track of them. *All* variables have to have
> names so you can use them in an equation. The names are an artifact of
> the use of equations. Equations breed names.
collector rather than a stack, but it definitely gives the same resulting
boost in productivity - you don't have to name or even maintain references
to objects that are created in the middle of operations.
I smile when I watch C programmers work in Smalltalk, because they want to
hold onto every little object by naming and referencing it.
Jon Hylands Jon@... http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot)
- View SourceDave Hyland had asked about the compession of code, and I had
mentioned the LLE project. Larry Forsley, who did it, wrote me
he was back from vacation, so I asked him about the details. He
sent an extended, but rather interesting reply. In particular
the last few paragraphs talk about "hacking" in the sense
research was done by interactive testing with tweaked constants
and hand adjustments, yeilded to verification of a patented
process of upconversion of photons. Dave, this is my basis to
say on a large project, not only the object produced will be
smaller, the source often compresses much more than most would
believe. I had suggested a 5:1 reduction, which people found
difficult to believe. Larry here documents an actual case ~100:1
reduction. Hope you enjoy the read, I did.:
The laser control power conditioning system that I built in the
late '70s was originally written in Fortran whose source code,
specification and documentation filled a shelf full of 3 inch 3
ring binders, probably close to 20 in all, which with tapes and
backups and things filled a good 6 - 8 foot shelf. The Forth
code, including the operating system source code fit in one 1
inch binder and the power conditioning source code was about 10
pages, or 30 Forth blocks.
The Fortran system also included a microcoded Hewlett Packard
21MX minicomputer that ran a relational description language
(RDL) I had devised prior to finding out about Forth in 1976 or
so. It was an interpretive system that stored spatial and
temporal relationships of components, sort of Smalltalk-like
(which I didn't learn about until the mid-80s). General
Electric Trident Missile Systems built the system to my and
another engineer's specifications.
However, GE signed up to deliver the system in August of 1977,
thinking that would be fine for meeting our September, 1977 DOE
milestone. Unfortunately, the milestone required an operating
laser, not just the power conditioning system.
One of our EE staff had gone up to Ottawa to a semiconductor
plant auction and bought two HP2114 computers: replete with 16K
words of core memory! My first inhouse Forth system went on
these, and, Ken Hardwick of the mainframe University computing
center, put a full multi-tasking, multi-user operating system,
URTH, or University of Rochester Forth on them. Ken had the
prescient to make the first high level version of ;code, that,
like Chuck, he also called ;: later to be renamed DOES>.
I took the system and put a full laser amplifier testbed
together and with one computer in Rochester and one at Raytheon
in Massachusetts, we "rang out" all of the laser amplifiers.
In the early spring of 1977, after I realized that GE wouldn't
give us the 3 months we needed to run the laser under automated
control, I commandeered Dan Gardner from GE (who hated Forth)
and we wrote a complete 6 beam laser power conditioning control
system. I think we started in April and were done by June.
That gave June, July and August to test the laser, while waiting
for the "real" laser control system to come on line. The test
only needed 4 beams, but the first experimental laser would be
the 6 beam Zeta, so I figured, what the hell!
Naturally, the top down build to the specs approach, so
"apropos" to the military and nuclear submarines, didn't work
too well with a small University embarked on building the
world's largest laser for fusion studies. As we wrote the Forth
code and found out how the laser really worked, bit sense or
control polarities were wrong, bit assignments were wrong, muxes
were wrong, etc, we fed that over to the software group so they
could correct the spec.
I always liked the idea of an "executable spec": e.g. the
At the end of the day, it was decided by Moshe Lubin, the
director of LLE, that since we'd spent a half million dollars
and probably 5 man-years building the "real" software, we'd
better use it. I fought this ridiculousness, but abstained at
Instead, the following systems came up in Forth:
24 beam laser alignment system, primarily written by my students
over a couple classes and two programmers, running on an LSI
11/23 with 256Kbytes of RAM, floppy disk and a 10 MB RL01 hard
drive, multiple color consoles, 24 tasks, etc. Lawrence
Livermore ran a 20 beam system on a VAX-780 networked through a
PDP-11/70 and hundreds of LSI 11/23 computers, each one
responsible for 4 mirror control systems in the laser. We
could align and shoot every 30 minutes. Livermore could do the
same every 2 hours.
There was probably 2 man-years of effort in LLE Laser control
system and easily 100+ man years in the Livermore system. I
discussed this with their engineers one time, and found that
probably 20% of their effort went into building a sufficiently
robust RS-232 based communications infrastructure to support the
communicating tasks, synchronizing them, etc, in the
Glass Development Laser (GDL, also known as the God Damn Laser)
power conditioning and safety interlocks for multiple
Optical Multichannel Analyzer (OMA) on the back of various
The GDL and OMA systems performance and flexibility allowed
Stephen Craxton, a British theoretical physicist, to verify his
2 wave mixing theory using "detuned" crystals to get 100%
conversion of infrared photons to ultraviolet photons (2 red ->
1 green, 1 red and 1 green -> UV). This saved laser fusion in
the mid-80's, and gained LLE a significant patent using two
birefringent crystals each "detuned" about the extraordinary
axis of rotation. This is the standard method through out the
world of building high power lasers for fusion and other
studies, as well as smaller systems for a variety of purposes.
Bob Boni, Steve Craxton, a GDL operator and occasionally me,
would run GDL nights when no one else was around to rotate the
crystal pairs, under Forth control, fire the laser, under Forth
control, operate the streak camera OMA, under Forth Control, and
within seconds of a shot know where we were on Steve's plots.
Then, we'd recycle the laser rotate the crystals or adjust the
laser power, and fire again. We literally stepped right through
Steve's curves, nailing them with experimental data.