TIL's and Forth
Walter Rottenkolber
Language. In the reference section he mentioned a language called IPS.
Thanks to the internet, I discovered that this was not only alive, but well,
and still at work.
IPS stands for "Interpreter for Process Structures". A book on it, in
English, was written by Karl Menizer in 1978, and it has been recently
reprinted and is for sale.
See: www.jrmiller.demon.co.uk/products/ipsbk.html .. Files for downloading
are also available at this site.
What's interesting is that it is still used to program the Amateur Radio
Satellites, the latest being Oscar-40, as well as the previous ones Phase
3A, Oscar 10 and Oscar 13. These are based on the RCA COSMAC 1802 cpu,
radiation hardened, which controls all of the satellite's internal
functions. See: www.amsat.org .
IPS was developed in German, and though some of the Words use the German
equiv. of English, some are uniquely German. For example: the branch words
are:
<expr> JA? <code> NICHT <code> DANN .
IPS, like Loeliger's TIL and STOIC, was developed in the mid-70's with some
knowledge of Forth, but before FIG released its Forth clone. As a result,
they all have two stacks and a dictionary, though some Word names and
functions are different.
To these I can add Pistol, a STOIC clone written in 'C', but this was
written later, as have a number of Forth variations and improvements to
present times.
However, does anyone know of any other Forth-like languages that existed
before FIG Forth?
Walter Rottenkolber
ko...@icm.edu.pl
>
> However, does anyone know of any other Forth-like languages that existed
> before FIG Forth?
Long time ago I heard about RPNL(Reverse Polish Notation Language) and
some HP calculator language. Just remember names though, wasn't interested
in Forth then.
Greetings :-)
Michal Gajda
ko...@icm.edu.pl
*knowledge-hungry student*
PS Did these languages you look for present any useful concepts not seen today?
Or they are just of historical interest?
cLIeNUX user
Ken Thompson's B, between BCPL and C, was implemented like a Forth, but
with one stack. They had a small machine to work with in 1971. I believe
the B compiler made threaded code executables. BCPL and B are
operator-typed, based on the concept of a cell.
MCPL is Richards' latest BCPL variant, and is fairly recent.
Rick
m_l...@yahoo.com
From what I read, it's unclear why it is better than a subset of ANS Forth.
Walter Rottenkolber
ko...@icm.edu.pl wrote in message ...
Thanks for the leads.
I haven't seen any concepts that haven't been more extensively explored in
recent Forth variants. I believe that most of these early TIL's came about
because the authors saw the advantages of Forth, but either couldn't spring
for the expense of the Forth license, or had a system Forth, Inc. didn't
support.
Walter Rottenkolber
Bernd Paysan
> Ken Thompson's B, between BCPL and C, was implemented like a Forth, but
> with one stack. They had a small machine to work with in 1971. I believe
> the B compiler made threaded code executables. BCPL and B are
> operator-typed, based on the concept of a cell.
The first C compiler was also threaded code (with one stack). Syntax
elements of C, like ++ or +=, came in to reduce the compiler size - each
of those added a bit size to the compiler, but on the other hand, using
these features (instead of e.g. var=var+1) reduced the size of the
compiler more than that (that's how Dennis Ritchie describes it). If he
had the idea of peephole optimizing threaded code, probably none of
those syntactical elements would be part of the C programming language.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
John Doty
> However, does anyone know of any other Forth-like languages that existed
> before FIG Forth?
In the late 1970's, Bob Goeke of MIT's Center for Space Research devised a
flexible embedded controller for lab instrumentation based on the 1802
processor. To program it, he devised a FORTH-like language he called "LSE"
(Laboratory Software Environment). LSE was influenced by Jon Sachs' STOIC
(Jon worked at MIT CSR 1972-1976), but was considerably simplified in
order to fit in an 8 kB ROM.
In LSE, the defining word *followed* the name of the definition, so a
typical definition might be:
add5 : 5 +
There were four definers:
: for indirect threaded code.
:code for machine code in hexadecimal.
:ascii for ASCII strings.
:variable for 16 bit variables.
In machine code, a + or - preceded a relocatable branch address, so C0-0F
was a relative backward branch by 15 locations.
Flow control was probably LSE's most eccentric feature. The words "if",
"ifz", "ifpz", and "ifn" each popped a value from the stack, and invoked
the following *single* word if the condition was satisfied (nonzero, zero,
positive or zero, and negative respectively). The word "repeat" was a jump
back to the beginning of the currently executing definition. One could
thus write:
Q if repeat
to invoke Q until it left a zero on the stack.
The CCD lab at MIT CSR adopted this system and used it to develop a series
of optical and x-ray CCD cameras for astronomical purposes. The 1802
controlled timing, shutters, raster generation, and temperature. In the
earliest version of this system, it even did the image processing through
a bus bridge to the external frame buffer memory! Later versions loaded
the images themselves directly into a UNIX workstation via DMA: an 1802 is
a bit underpowered for image processing.
It was a terrific match to the lab's needs. In the early days, the CCD lab
essentially just George Ricker and a bunch of students. Bob's highly
demultiplexed backplane proved very easy to comprehend: inexperienced
students were very successful at devising interfaces for a wide variety of
devices. In 1980, very few students came in the door knowing a programming
language suitable for embedded applications. LSE was very simple and easy
to learn.
George asked me to join his lab in 1981. I found a well developed hardware
and code base for his optical astronomical camera, but we needed more
flexibility to handle new CCD types and move into the x-ray range. Charlie
Hulcher, one of my students, put together a microprogrammable raster
generator based on an 8X300 processor. This thing had program memory but
no data memory: the control bits were just an extension of the CPU
instruction. I wrote an assembler for it in LSE, and then a compiler for a
specialized language that was all loops and I/O, but no run time
variables:
100 FOR
P3 HIGH EXECUTE
5 MICROSEC DELAY
P3 LOW EXECUTE
5 MICROSEC DELAY
NEXT
would generate the microcode to cycle the "P3" clock 100 times at a
frequency of 100 kHz.
Memories on these new systems were also bigger, so I added the structured
flow control Bob had left out of his original LSE implementation. Of
course, since I was building it on top of an eccentric foundation, and
staying compatible with our existing code base, it came out somewhat more
eccentric:
test-clause if { then-clause }{ else-clause }
loop-count [ bound-loop-body ]
do[ unbound-loop-body ]
We built a long series of x-ray and optical systems with this approach. In
1988, I was returning from a conference in Japan. The stewardess was
distributing copies the Japan Times. On page 2 I learned that Jim Elliot's
group from MIT had just discovered that Pluto has an atmosphere, using
NASA's Kuiper Airborne Observatory. That was a big thrill, as I knew the
camera he was using was one of this series.
By this time, however, the LSE approach was getting to be a burden. The
biggest problem was that I wound up the maintainer of all of the code. I
do not find it difficult to read code in this sort of language, but I've
never been able to teach this skill. This wasn't a big deal when it was
only a few students and me writing code, but by 1988 we were hard at work
on one big project (focal planes for the ASCA spacecraft), with two more
space missions (HETE-1 and Chandra) on the near horizon. I was Project
Engineer for the ASCA focal planes, Project Scientist for HETE, and had
various less formal jobs on Chandra, with a rapidly growing professional
staff: too many responsibilities to allow me to also be a full-time
software maintainer.
Most of the people doing programming, both students and professionals,
were now coming in the door knowing C. C offered enormous advantages in
terms of familiarity, readability, and portability. In addition, we found
ourselves implementing most of the low level controller functions in FPGA
hardware rather than in software. We thus gradually phased out the
1802/LSE systems.
We still have a few of these systems around, but they aren't in service.
There may still be one in service at Goddard Space Flight Center testing
x-ray optics, but I don't know for sure.
--
| John Doty "You can't confuse me, that's my job."
| Home: j...@w-d.org
| Work: j...@space.mit.edu
Walter Rottenkolber
John Doty wrote in message ...
>
>In the late 1970's, Bob Goeke of MIT's Center for Space Research devised a
>flexible embedded controller for lab instrumentation based on the 1802
>processor. To program it, he devised a FORTH-like language he called "LSE"
>(Laboratory Software Environment). LSE was influenced by Jon Sachs' STOIC
>(Jon worked at MIT CSR 1972-1976), but was considerably simplified in
>order to fit in an 8 kB ROM.
>
>
>100 FOR
> P3 HIGH EXECUTE
> 5 MICROSEC DELAY
> P3 LOW EXECUTE
> 5 MICROSEC DELAY
>NEXT
>
>would generate the microcode to cycle the "P3" clock 100 times at a
>frequency of 100 kHz.
>
The story of LSE is quite interesting. It appears to have been developed for
reasons similar to IPS.
As a derivative of STOIC, did LSE also compile everything, even commandline
code entries? In your loop example, you mentioned microcode. Did LSE
compile this source code to the dictionary or did it generate machine code?
Walter Rottenkolber
John Doty
<wal...@sierratel.com> wrote:
> As a derivative of STOIC, did LSE also compile everything, even
> commandline code entries?
If my memory is correct and I understand the sense of your question, the
answer is yes (but I have been known to be confused!).
> In your loop example, you mentioned microcode. Did LSE compile this
> source code to the dictionary or did it generate machine code?
The microcode was compiled directly into the clock generator's memory.
Compile time for the microcode compiler was run time for LSE. One could
use LSE definitions as "macros", so the example I gave could also have
been written:
e5m : EXECUTE 5 MICROSEC DELAY
100 FOR
P3 HIGH e5m P3 LOW e5m
NEXT
The dictionary was not involved when compiling microcode. The microcode
compiler was just a bunch of ordinary words that, when executed, did
things to the clock generator's memory and some global data structures.
When done compiling microcode one could optionally create a dictionary
entry and read the microcode into it. This would allow you to reload that
microcode later without having to recompile it.
--