The early years of the FORT

image

KDPV taken from here

Introduction


FORT is a simple and natural computer language. It has received significant distribution where high efficiency is needed. In the 60s he went the way of development from universities through business to laboratories. This is a story about how a simple interpreter expanded its capabilities and was able to become a full-fledged programming language and operating system.

This work was written for a conference on the history of programming languages ​​- HOPL II. She was ultimately rejected, probably due to her presentation style.

FORT spread in the sixties in America - in universities, business and science, along with other developed languages. At that time I was the only programmer on it, until the very end of this period it had no name. Everything described here is recovered from memory, fragmentary documentation, and surviving program listings.

FORT as a whole is hardly original, but it is a unique combination of components. I am grateful to those people and organizations that allowed me to develop it - often without knowing it myself. And I thank you for your interest in making you read about it.

FORT is a simple and natural computer language. Today [1991 - approx. trans.] It is considered a world-class programming language. The fact that he reached such a level without the support of industry, universities or government is a consequence of its effectiveness, reliability and versatility. Fort is a language that is chosen when its effectiveness is more important than the popularity of other languages. This is a frequent case in practical areas such as control and communications systems.

Many FORT organizations and many small companies offer systems, applications, and documentation. In North America, Europe and Asia, annual conferences are held. The draft ANSI standard [ANS 1991] will be presented shortly.

None of the books about the FORT fully describe his “taste." I think that the best is still the first of them - “Starting Forth” by Leo Brodie [available, for example, here - https://www.forth.com/starting-forth/ - approx. transl.] .

The classic FORT that we are discussing provides minimal sufficient support for the programmer to develop the language best for his application. It is intended for such an environment as a workstation, including a keyboard, display, computer and drive [in those days, disk drives were often external, so the author simply lists the components of a minimal computer system - approx. transl.] .

FORT is essentially a context-free text language. It allows you to combine “words”, separated by spaces, to construct new “words”. About 150 of these words make up a system that provides:

         SAO  1958  
        SLAC  1961   
         RSI  1966    ,   , 
     Mohasco  1968  ,  , ,  ,
                    
        NRAO  1971   *,    

* Embroidered code is a method of compiling a program in which it is an array of subprogram calls, see https://en.wikipedia.org/wiki/Threaded_code - approx. perev.

Such a system contains from 3 to 8 kilobytes of program code compiled from 10-20 pages of source code. It can easily be developed by one programmer, even on a computer with limited resources.

This text necessarily describes my career; but he was conceived as a “biography” of the FORT. I will discuss the FORT features listed above and the names of the “words” associated with them. The meanings of many “words” are obvious. Some require a description, and some go beyond the scope of this work.

The part of the FORT language dictionary to be considered is listed below:


     WORD  NUMBER  INTERPRET  ABORT
     HASH  FIND  '  FORGET
     BASE  OCTAL  DECIMAL  HEX
     LOAD  EXIT  EXECUTE  (
 (  )
     KEY  EXPECT
     EMIT  CR  SPACE  SPACES  DIGIT  TYPE  DUMP
 
     DUP  DROP  SWAP  OVER
     +  -  *  /  MOD  NEGATE
     ABS  MAX  MIN
     AND  OR  XOR  NOT
     0<  0=  =
     @  !  +!  C@  C!
     SQRT  SIN.COS  ATAN  EXP  LOG
 
     :  ;  PUSH  POP  I
 (   )
     BLOCK  UPDATE  FLUSH  BUFFER  PREV  OLDEST

     CREATE  ALLOT  ,  SMUDGE
     VARIABLE  CONSTANT
     [  ]  LITERAL  ."  COMPILE
     BEGIN  UNTIL  AGAIN  WHILE  REPEAT
     DO  LOOP  +LOOP  IF  ELSE  THEN


MIT, SAO, 1958


The most exciting time was October 1957, when Sputnik was launched [Sputnik-1 satellite - approx. transl.] . I was a second year student at MIT and worked part-time at SAO (Smithsonian Astrophysical Observatory, as many as 16 syllables, a nightmare) at Harvard. The observatory was responsible for the optical tracking of satellites - visual observations using the moon [meaning Project Moonwatch - https://en.wikipedia.org/wiki/Operation_Moonwatch - approx. transl.] and satellite tracking cameras [Baker-Noon cameras - https://en.wikipedia.org/wiki/Schmidt_camera#Baker-Nunn - approx. perev.]. Caught by surprise, they hired students to figure out trajectories on Friden desktop calculators. John Gaustad told me about the IBM EDPM 704 at MIT and lent me his FORTRAN II manual. As a result, my first program, Ephemeris 4, left me without a job.

Now, already in the role of a programmer, I worked with George Veis to apply his least squares method to determine the parameters of orbits, stationary positions, and ultimately to determine the shape of the Earth. Of course, this “part-time job” took at least 40 hours, and yet, yes, my diploma was covered.

John McCarthy taught an excellent LISP course at MIT. This course was my introduction to recursion and the wonderful variety of programming languages. Wil Baden noted that LISP for lambda calculus is the same as FORT for the postfix notation Lukasewcleicz [Lukashevich’s notation, also known as the reverse Polish notation - approx. transl.] .

The submarine was also relevant, with its strange analysis from right to left. Although I admire him and imitate his operators, I am not convinced that they make up the optimal set.

Programming in the fifties was harsher than it is today. My source code took up 2 punch cards. To get them through the car, I had to tinker, and basically I did it myself. The assembly took half an hour (just like in C), but limited computer time meant only one launch per day, except, perhaps, for the third shift.

And so I wrote a simple interpreter that reads cards with input data and controls the program. He also controlled computing. For each of the five parameters of the orbit, there were empirical equations for taking into account atmospheric drift and deviations of the Earth's shape from the sphere. In this way, I could compose various equations for several satellites without recompiling the program.

Factors such as P2 (second-degree polynomial) and S (sine) participated in these equations. Most of the time, 36-bit floating-point computing took up, so the overhead was low. The data stack was not needed, but I probably did not know about it.

And so the story of the FORT interpreter began - from the words

WORD  NUMBER  INTERPRET  ABORT


They have not yet been recorded in words, because they were operator numbers.

INTERPRET uses WORD to read words separated by spaces, and NUMBER to convert words [numbers in a text record - approx. translate.] in binary form (in this case, with a fixed point). Such input in free format was unusual, but more efficient (smaller and faster), and more reliable. Fortran style input was formatted into specific columns, and typos caused numerous delays.

This interpreter used the IF ... ELSE IF construct encoded in FORTRAN to match each character. All error handling was simply interrupting the execution of the program. Then, as now, the word ABORTasking the user what to do. Since the input cards were numbered in the reading order, you could find out where the error was.

Stanford, SLAC, 1961


In 1961, I came to Stanford to study mathematics. Although Stanford created his own computer science department, I was more interested in computing. I was impressed that they could (dare?) Write their own ALGOL compiler. And yet - fate brought me to the Burroughs B5500 computer. I again hired to work part-time at SLAC (Stanford Linear Accelerator, 10 syllables), write code to optimize beam retention in a future three-kilometer electron accelerator. This was a natural application of the least squares method (in which I had experience) to phase space. Hal Butler was responsible for our group, and our TRANSPORT program was a success.

Another application of the least squares method was the CURVE program, written in 1964 on ALGOL. It was a universal program for nonlinear data selection with differential correction. Its statistical rigor provided a detailed analysis of the consistency of the model and experimental data.

The data format and model equations were interpreted, and a stack was used to facilitate calculations. CURVE was an impressive forerunner of FORT. To provide the opportunity to work not with simple equations, but with much more elaborate models, she introduced the following words:

     +  -  *  NEGATE
     IF  ELSE  THEN  <
     DUP  DROP  SWAP
     :  ;  VARIABLE  !  (
     SIN  ATAN  EXP  LOG


The spelling was slightly different:

     NEGATE  -    MINUS
       DROP  -    ;
       SWAP  -    .
          !  -    <
   VARIABLE  -    DECLARE
          ;  -    END
     ( ...)  -    COMMENT ...;


To define a six-character input word (called ATOM by analogy with LISP), the interpreter used IF ... ELSE IF . DUP , DROP and SWAP were machine instructions; I was surprised that they were written differently. The word “ : ” (colon) was taken from the label format in ALGOL, and was “flipped” to parse from left to right (to prevent the interpreter from detecting undefined words):

     ALGOL - LABEL:
     CURVE - : LABEL

In fact, the colon marked the position in the input line, which was to be interpreted later. The interpretation was stopped by the word “ ; " (semicolon). One version of the colon was called DEFINE .

Record Operator " ! "(Exclamation mark) appeared in connection with VARIABLE ; but reading “ @ ” was automatic. Please note - the code has become complicated enough to require comments. The once-criticized postfix condition began from here:

     ALGOL - IF expression THEN true ELSE false
     CURVE - stack IF true ELSE false THEN

If there was a nonzero value on the top of the stack, it was perceived as a Boolean true value (true). THEN provided a unique ending, the absence of which always confused me in ALGOL. Similar expressions were interpreted as follows: IF scanned the input for ELSE or THEN . The word < introduced the convention that a relation leaves a boolean value on the stack - 1 if true, and 0 if false. Transcendental functions are, of course, calls to library routines.

On free bread


I left Stanford in 1965 to become a freelance computer programmer in New York. This was not unusual, and I found work programming in FORTRAN, ALGOL, Jovial, PL / I and various assemblers. I literally dragged around with my pack of punch cards and reprogrammed it as needed. Mini-computers appeared, and with them - terminals. The interpreter was perfect for teletype input, and soon acquired code for working with output. So we found the words:

     KEY  EXPECT
     EMIT  CR  SPACE  SPACES  DIGIT  TYPE

EXPECT is a loop that calls KEY to read keystrokes. TYPE is a loop that calls EMIT to display a character.

With the advent of teletype, it is time for punched tape and the most uncomfortable programs you can imagine - requiring many hours of editing, punching, loading, assembling, printing, downloading, testing, and then again. I remember a terrible Sunday in a skyscraper in Manhattan, when I could not find duct tape (nothing else helped), and cursed that "there must be a better way."

I did a decent job for Bob Davis at Realtime Systems, Inc (RSI). I thoroughly studied 5500 MCP - enough to support its time sharing service (working with remote terminals), and also wrote a translator from FORTRAN to ALGOL and file editing utilities. The translator showed me the value of spaces between words that FORTRAN does not require.

The interpreter still only distinguished words by the first 6 characters (since the data word in the Burroughs B5500 was 48-bit). The words LIST EDIT BEGIN AGAIN EXIT appeared .

The words BEGIN ... AGAIN were written as START ... REPEAT and served as “brackets” for the editing commands T TYPE I INSERT D DELETE F FINDlater used in the NRAO editor.

The word FIELD was used in Mohasco's Forth DBMS style. Hence one of the hallmarks of FORT. The rule is that the FORT confirms each line of input by adding OK when the interpretation is complete. This can be troublesome, since when the input terminates with a CR character, a space should be displayed, then OK, and CR last. In RSI, OK, I found myself on the next line, but nevertheless passed friendly confirmation via a frightening communication line [an author’s joke based on the fact that in those years the work of computers with communication lines was unusual; for the modern reader, the joke has already lost its relevance and sounds, at least, strange - approx. transl.] :

     56 INSERT ALGOL IS VERY ADAPTABLE
     OK


This postfix notation suggests the use of a data stack, but its sufficient depth is only one.

Mohasco, 1968


In 1968, I came to work as a programmer at the commercial company Mohasco Industries, Inc in Amsterdam, New York. It was a large company producing home goods - carpets and furniture. I worked with Geoff Leach at RSI, and he convinced me to move him to the northern part of the state. I just got married, and in Amsterdam there was a wonderful atmosphere of a small town, contrasting with New York.

I rewrote my code on COBOL and found out what business software really is. Bob Raiko was responsible for corporate data processing and gave me two related projects.

He rented an IBM 1130 mini-computer with a 2250 graphic display. The goal was to see if computer graphics could help create patterned rugs. The answer was “can't help without color support,” and the 1130 option was no longer available.

At that time I had the latest minicomputer: 16-bit processor, 8K RAM, disk drive (the first in my life), keyboard, printer, card reader and punch, FORTRAN compiler. The reader and punch were a backup option in the event of a disk failure. I again ported my interpreter (back to FORTRAN) and added cross-assembler to work with 2250.

The system was awesome. She could draw animated three-dimensional images when IBM could hardly draw static flat pictures. Since this was my first real-time graphics, I wrote the code for Spacewar, the very first video game. I also rewritten my FORT chess program, originally written in ALGOL, and was very impressed with how much easier it became.

The file containing the interpreter was called FORTH, which meant the fourth (next) generation software, FOURTH. But the name had to be shortened, since the operating system limited the file names to 5 characters.

This programming environment for the 2250 was far superior to FORTRAN, so I expanded the 2250 cross assembler to the 1130 compiler. There were a lot of new words:

     DO  LOOP  UNTIL
     BLOCK  LOAD  UPDATE  FLUSH
     BASE  CONTEXT  STATE  INTERPRET  DUMP
     CREATE  CODE  ;CODE  CONSTANT  SMUDGE
     @  OVER  AND  OR  NOT  0=  0< 


Their spelling was still different [from the standard for FORT - approx. transl.] :

      LOOP     CONTINUE
     UNTIL -      END
     BLOCK -      GET
      LOAD -      READ
      TYPE -      SEND
 INTERPRET -      QUERY
    CREATE -      ENTER
      CODE -       


This was the only application I have ever found for a cent symbol.

The counter and the loop limit were stored in the data stack. DO and CONTINUE came about thanks to FORTRAN.

BLOCK controlled the number of buffers to minimize disk accesses. LOAD read the source code from a block of 1024 bytes in size. The size of 1024 bytes was chosen based on the size of the block on the disk, and was successful. The word UPDATE allowed you to mark a block in memory and later flush it to disk when you need to free the buffer (or by the word FLUSH ). It implements a kind of virtual memory and is implicitly called during write operations.

The word BASEAllowed to work with octal, hexadecimal and decimal numbers. The word CONTEXT was the first hint of dictionaries and served to separate the words of the editor. The word STATE set compilation and interpretation modes. During compilation, the number of characters and the first 3 characters of the word were compiled [compiled into identifier - approx. transl.] for subsequent interpretation. Oddly enough, words could be interrupted by special characters - but this was soon abandoned. The read operator ( @ ) had many options, since reading from variables, arrays, and the disk needed to be distinguished. DUMP allowed to dig into memory for debugging.

But most importantly, there was now a dictionary. The interpreter code now took a name and looked for it in a linked list. The word CREATE created a classic vocabulary entry:

   *       
   *     3  *
   *  ,   
   *  

* FORT identifiers are packed in 32 bits in the form: 1 byte - the number of characters in the word, the remaining 3 bytes - the first 3 characters of the word (hussars, be silent!) - approx. perev.

The code field was an important innovation - as soon as the word was found, only one indirect transition remained from the interpreter overhead. I learned about the meaning of the number of characters in distinguishing words from compiler developers at Stanford.

The word CODE has created an important class of words. Its parameter field contained machine instructions. Thus, now it was possible to create any word within the capabilities of a computer. The word " ; CODE " defined the code that was to be executed for the new class of words, and introduced what is now called objects.

WordSMUDGE avoided recursion during interpretation of definitions. Due to viewing the dictionary in order from the newest definitions to the oldest, unwanted recursion was common.

Finally, a return stack appeared. Prior to this, the definitions could not be nested, or had to store the return address in the data stack. All in all, it was a time of great innovation in the (intermittent) development of the Fort.

Geoff Leach and I wrote the first article about the FORT (in the form of an internal Mohasco report) in 1970. She has not lost relevance today.

In 1970, Bob ordered the Univac 1108. It was an ambitious project to support a dedicated line network for an order entry system. I wrote a report generator on FORT, but I was sure that I could write a code for entering orders. To increase confidence in the FORT, I ported it to 5500 (as a separate program!). But the corporate software was COBOL. Surprisingly, a compromise was achieved by setting the FORT system to 1108 so that it interacted with COBOL modules for transaction processing.

I remember very well the trip to Schenectady that winter to take time on the third shift at 1107. There was no floor and window in my room, and this was a nightly exercise in survival. But the system turned out to be incredibly successful, and impressed even Univac (Les Sharp was involved in integration with the project). The decisive criterion was the response time, but I was also determined to maintain the project in a suitable form for maintenance (that is, to keep it small and simple). Alas, the economic downturn forced management to cancel 1108. I still think it was a bad decision. I was the first to resign.

Fort for 1108 would have to be written in assembler. It buffered input and output messages and distributed the processor between tasks processing each line. Here you have the classic operating system. But he could also parse the input lines and execute (with the word PERFORM ) the corresponding COBOL modules. He monitored the buffers of the memory drum and was involved in packing and unpacking records. The words

     BUFFER  PREV  OLDEST
     TASK  ACTIVATE  GET  RELEASE


appeared just then.

BUFFER did not read the disk if it was known that the requested block is empty. PREV and OLDEST are system variables that make it possible to implement buffer management on a “least used” basis. TASK defined the task at boot time, and ACTIVATE ran it when needed. GET and RELEASE controlled shared resources (memory drum, printer). PAUSE is the word by which the task frees the processor. It was included in all I / O operations and was invisible to the transaction code. It made possible a simple cyclic scheduling algorithm that avoids blocking.

After the statement[probably about dismissal - approx. trans.] I wrote an angry poem and a book that was never published. It described how to program in FORT and encouraged simplicity and innovation. It also describes the technique of indirect sewn code, but for the first time it was implemented in NRAO.

I worked on the concept of metalanguage - a language that speaks of a language. Fort could now interpret the assembler that the compiler assembled, which compiled the interpreter. In the end, I decided that the terminology did not work, but the term “metacompilation” for recompiling the FORT itself was still in use.

NRAO, 1971


George Conant offered me a position in the NRAO (National Radio Astronomy Observatory, 22 syllables). I knew him at CAO and he liked Ephemeris 4. We moved to Charlottesville, Virginia and spent the summer in Tucson, Arizona when the Kitt Peak radio telescope was available for maintenance.

The project involved programming the Honeywell 316 minicomputer to control a new filter bank for a 36-inch millimeter-wave radio telescope. He had a nine-track magnetic tape and a Tektronix tube terminal with a “memory” [probably referring to afterglow tubes or potentioscopes - approx. perev.]. George gave me complete freedom in developing the system, but he was not happy with the result. In NRAO everyone used FORTRAN, and now I appeared with my FORT. He was right that organization standards should provide for one common programming language. Other programmers now also want their own languages.

Be that as it may, I wrote the FORT code in assembler on the IBM 360/50 mainframe. Then I recompiled it under 316. Then I natively compiled it to 316 (although I had a 360 terminal, the response time was terrible). Once the system became available, then it was easy. There were two observation modes: all-frequency and spectral lines. The spectral lines were most interesting, because I could display the spectra as I collected the data, and smooth out the shapes of the lines using the least squares method.

In Tucson, where Ned Conklin led, the system was well received. This was another step in reducing the amount of data immediately as it was collected. Astronomers began to use it to detect and map interstellar molecules, as soon as this became a fashionable area of ​​research.

Bess Rather was hired to support the observatory. First she had to study the FORT system, and then explain and document it with minimal help on my part. The following year, I reprogrammed the DDP-116 to optimize telescope pointing. Then Bess and I replaced the DDP-116 and Honeywell 316 with the DEC PDP-11.

Such a replacement became possible due to the development of indirect sewn code. This was a natural development of my work at Mohasco, although I later learned that DEC used direct sewn code in one of its compilers. Instead of compiling the entire definition each time, the compiler simply took the address of each word used from the dictionary. This performance improvement for each link required only two bytes, and the interpreter could execute the code much faster. On DEC PDP-11, this interpreter was essentially a two-word macro:

: NEXT IP )+ W MOV W )+ ) JMP ;


Now the FORT has been completed. And I knew that. I could write code faster and it was more efficient and reliable. Moreover, it was portable. I continued to reprogram the DDP-116, which focuses on pointing the 300-inch Green Bank telescope, and the HP mini, which began with very long base radio astronomy (VLBI). George gave me ModComp, and I programmed the Fourier transform for interferometry and pulsar search (on 64K data sets). I even demonstrated that complex multiplication by IBM 360 in FORT was 20% faster than in assembler.

The NRAO appreciated what I wrote. They had an agreement with a consulting firm to identify collateral technologies. The issue of FORT patenting has been discussed for quite some time. But since software patents were contradictory and could be resolved with the involvement of the Supreme Court, the NRAO refused to deal with this issue. As a result, the copyrights returned to me. I do not think that ideas should be patented. Looking back, one should agree that the only chance of FORT is to remain in the public domain. And there he flourished.

The sewn code changed structural words (such as DO LOOP IF THEN ). They got an elegant implementation with addresses in the data stack at compile time.

Now each implementation of the fort had assembler for the architecture of its computer. He used opcodes in postfix notation, and generated addresses in the data stack, with FORT-like structured words for branching. Assembler mnemonics were defined as word classes using ; CODE . It was possible to encode this all in one day.

Unusual arithmetic operators have also proven their worth.

M*  */  /MOD  SQRT  SIN.COS  ATAN  EXP  LOG


M * is the usual hardware multiplication of two 16-bit numbers into a 32-bit product (arguments, of course, in the data stack). It is followed by * / with division to implement fractional arithmetic. / MOD returns both the quotient and the remainder, and is ideal for finding entries in a file. SQRT returns a 16-bit result from a 32-bit argument. SIN.COS immediately returns both sine and cosine, which is useful for vector and complex arithmetic (FFT). ATAN is the inverse operation, and has no quadrant ambiguities. EXP and LOG are calculated in base 2.

In these functions, fixed-point arithmetic was used - 14 or 30 bits to the right of the binary point for trigonometry, 10 for logarithms. This has become a hallmark of FORT, since such arithmetic is simpler, faster and more accurate than floating point. But if necessary, you can easily implement hardware and software with a floating point.

I applaud the invaluable work of Hart, who compiled tables of approximations of functions with different accuracy. They freed application programmers from the limitations of existing libraries.

The word DOES> appeared (it was written as ;:) . It defined a class of words (like ; CODE), establishing that the definition should be interpreted when referring to a word. It was difficult to implement, but it turned out to be especially useful for defining operation codes.

However, I was not able to convince Charlottesville that FORT suits them. I was not allowed to program VLA. In any group of programmers, 25% love Fort and 25% hate it. Disputes are tough, and compromise is rarely reached. As a result, the first 25% joined forces and created Forth, Inc. But that's another story.

Morality


The history of FORT has a certain morality: a persistent young programmer fights against indifference in order to discover the Truth and save his suffering comrades. It’s getting better: watch Forth, Inc. go head to head with IBM in the French banking system.

I know that FORT is still the best programming language. I am pleased with his success, especially in the ultra-conservative field of artificial intelligence [recall, 1991 - approx. transl.] .

My concern is that those people who should not appreciate how the FORT embodies their own description of the ideal programming language.

But I'm still doing research without a license. FORT has led to an architecture that promises an amazing combination of hardware and software. As well as another new programming environment.

All Articles