Fort (programming language)

Creation

The Fort language was created by Charles X. Moore in the late 1960s and early 1970s. Moore called his language Fourth , believing that it would be the language for computers of the fourth ( English fourth ) generation. But since he was working on an IBM 1130 machine , which allowed names made up of no more than five capital letters, the name was converted to FORTH ( English forth - forward). However, Moore's first experiments to create a simple interpreter to facilitate the writing of astronomical equipment control programs date back to the late 1950s. ^[3]

Since 1971, Moore worked at the National Radio Astronomy Observatory , Participating in the development of programs for collecting and processing data received by the radio telescope . It was then that the first implementation of the Fort language appeared. Elizabeth Rather, an employee of Moore, was also involved in this work. She can be considered the second fort-programmer in the world.

The newly created language was adopted as the main programming language in the American Astronomical Society . Later, in 1973, Charles Moore and Elizabeth Rater founded FORTH, Inc ^[4] , during which over the next decade the language was ported to many platforms.

In the late 1970s, programmers interested in developing the language created the FORTH Interest Group (FIG). This group developed the FIG Forth Model concept - a public fort system that can be easily ported to popular computer architectures. This reference fort system — FIG-FORTH — is often considered the original language standard.

Standardization

The idea of ​​official standardization of the Fort originally arose as part of the International Association of Astronomers ( Eng. Astronomical Sciences, AST ). In May 1977, at a meeting at the Kitt Peak National Observatory ( USA ), a Fort glossary was developed, designated AST.01.

In February 1978, Utrecht adopted the FORTH-77 standard, focused on implementation on microcomputers .

In October 1979, a meeting on Santa Catalina Island ( California ) ended with the development of the FORTH-79 standard, which applies to all types of computers.

In the fall of 1983, a meeting was held to develop the next standard, approved in 1984 as FORTH-83. The Fort-83 standard differs from the Fort-79 standard in some details, but not in essence.

In 1988, SIGFORTH was formed as part of ACM ^[5] ; there was also the corresponding Russian ACM group (chairman - prof. S.N. Baranov ( St. Petersburg , SPIIRAS )). SIGFORTH now exists as part of the more general SIGPLAN group.

Finally, in 1994, after lengthy coordination, in which many interested firms participated, the ANSI Fort language standard was adopted. ^[6]

Further development and examples of use

A well-known example of the Fort’s successful use is its use in deep-sea descent software when searching for the Titanic in 1985 . The Fort was also used in Shuttle spectrograph software, in micromodules for controlling artificial satellites of the Earth, for a control system at Riyadh airport , computer vision systems , blood analysis and cardiac monitoring automation, pocket translators.

The Fort language dialect is used in OpenBoot , the basic computer software based on SPARC and PowerPC processors .

In the early 1980s, Fort John John Warnock and Chuck Geschke of Adobe Systems created the PostScript language ^[7] , which is widely used to control printing devices and served as the basis for creating the PDF format.

There are processors and controllers that support the computational model of the language at the hardware level. Many open Fort implementations have been created for various hardware platforms. Some companies (among which it is worth noting, first of all, that FORTH, Inc., founded by Charles Moore, and the British company MicroProcessor Engineering Ltd. ^[8] ) supply commercial versions of the language that are different in their capabilities.

EuroForth conferences are held annually, including in Russia, England, Austria, Germany, Spain, the Czech Republic (previously in Czechoslovakia). ^[9]

The main part of the Fort system is a linked list of words , or a dictionary from which a word is called by name to perform specific functions. Programming at Fort consists of defining new words based on the words defined in the dictionary earlier. As soon as new words are compiled into the dictionary, they do not differ in form from the words that were already in it. The description of a word in a dictionary is called an article .

The structure of a “typical” Fort dictionary article:

• name field - contains the name of the article (word identifier) ​​in the form of a string with a counter, as well as several flags.
• link field - a pointer to the previous article.
• code field - a pointer to the code for interpreting the article.
• parameter field - semantics of the word (depending on the code field).

Conventionally, Fort articles can be divided into two categories: low-level articles and Fort articles . Articles of the first type contain in the code field a pointer to a procedure in the codes of the target processor that directly performs the semantics of the word. In the parameters field of such articles are the parameters passed to the procedure, or its code itself. Fort articles contain pointers to other articles in the parameter field, and the code field points to a special procedure called the link interpreter . In practice, the structure of the article depends on the implementation, but, as a rule, is similar to the one discussed above. The principle used inside the parameter field of the fort article is called the sewn code ( English threaded code ), and the link interpreter is called the virtual Fort machine .

The grammatically text processed by the Fort translator is a sequence of tokens , separated by spaces and end-of-line characters. The input line translator selects the next token and searches for it in the current dictionary, and the search is from newer to old words. If the word is not found, an attempt is made to interpret the token as a record of a number, which, if successful, is placed on the top of the stack. If the token matches the word of Fort, the current state of the compile flag of the Fort system is analyzed. If the flag is cleared, then the word is executed - control is transferred by the code field pointer of the found article. If the flag is set, the word is compiled , that is, a pointer to its code field is added to the current article being created. If a number was translated, it is removed from the stack and compiled into literal code , the execution of which inside the dictionary entry puts the number on top of the stack. In addition, words can contain the immediate flag, in which case they are always executed.

The mechanism for passing parameters between words:

• through the data stack;
• through memory cells;
• through named local variables (1994 standard).

The language provides a way to work with the system’s memory as a linear region.

A mandatory component of the system is also the return stack. Available programmatically to change the control flow of a program.

All of the above applies to the concept of Fort only as a first approximation. Fort is not quite a programming language; rather, it overlaps the concept of a programming language. The fort is more of a virtual machine and ForthOS operating system. ^[10]

The syntax and semantics of the Fort can be expanded to any other programming language right during the interpretation (compilation) of the Fort program. Using Fort as a metalanguage is convenient due to the availability of Fort tools that support those languages ​​that are already in the Fort system. All resources of the Fort system are available to the user and are presented in the form of dictionary entries. As a rule, user-defined dictionary entries have exactly the same representation in the Fort system as all other dictionary entries that make up the entire Fort system.

One or another type of sewn code is used as a machine representation of a compiled fort program.

When using the subprogram code , a machine code is obtained in which, in comparison with the code generated by the compiler of a common programming language, where variables and return addresses from subprograms are put on a single stack, there are no operations for dragging and dropping subprogram parameters. The main processor stack is used as the return stack, the data stack is organized programmatically.

When using sewn code that differs from the subroutine, Fort definitions consisting only of machine code are called primitives . In such sewn code, they often try to use the main processor stack as a data stack, and accessing the data lying on it in the form of machine commands pop and push .

One of the not quite obvious advantages of using indirect sewn code is that all machine code, that is, primitives, calls to the code interpreter and variables, can be placed in one segment of code that will not be available for change. The rest of the Fort code is located in the data segment. There can be many of these segments, and working with a single segment number is easier than with two.

Fort systems can also use bytecode as the logical conclusion to the development of indirect sewn code and folded sewn code with an address table. In this case, the program (Fort) code is a sequence of bytes, or the code of some invented virtual processor. To execute this code, there must be a table with 256 addresses (2-byte, 4- or 8-byte), on which Fort primitives or complex definitions are located.

This option is very different from other types of code and deserves special attention.

• As in indirect sewn code, Fort primitives can be located in a single code segment, protected from interference, flashed in ROM. Primitives depend on a specific platform and can be implemented as a separate block. The rest of the Fort is platform independent and portable to any machine.
• Around a table of 256 definitions a separate dictionary is grouped, a lexicon designed for a specific task or group of tasks. These 256 definitions take up no more than 64K, that is, the table can contain 2-byte addresses (offsets relative to the beginning of the dictionary).
• Byte code allows you to expand the number of definitions due to the tree structure of dictionaries to any size, while maintaining the minimum program size.
• Byte code can be standardized. Like Java , such code can be quickly forwarded over the network and executed on machines with any platform.
• Byte code allows you to emulate any processor or software system and debug programs designed for them.

  .( Hello World)

An example of the definition of the word .SIGN that prints the corresponding phrase depending on the sign of the number on the top of the stack:

  \ Type a number sign
 : .SIGN (n -)
    ? DUP 0 = IF
      . "ZERO"
    ELSE
      0> IF
      . "POSITIVE NUMBER" ELSE
      . "NEGATIVE NUMBER" THEN
    THEN
 ;

An example of real code that creates a string constant in the form accepted in the Fort (with a counter):

  \ Create a "constant" from a string
 : S-CONSTANT (c-addr u "<spaces> name" -)
    CREATE 
      DUP, 0? DO
        DUP C @ C, CHAR +
      LOOP DROP 0 C,
    DOES>
      DUP CELL + SWAP @
 ;

This example creates a definition for the word name using the word CREATE . When the word name is executed, the address of the pointer to the memory area that was during the compilation of the word will be put on the stack. In order to be able to use it somehow, it writes there (the string is “compiled”). When the word is executed, the words specified after the word DOES> .

Thus, a new syntax construct was created in this example. Such capabilities are rarely represented in other programming languages.

In addition to creating new syntactic constructions, one of the most powerful features of the Fort is the ability to intervene in the compilation process using immediate-execution words (immediate-words).

Examples of such standard words:

[ - Temporary switching to runtime (in fact, it often just writes 0 to the STATE variable).

] - Switch back to compilation mode.

LITERAL - Compile the number currently at the top of the stack as a constant. Also a word of immediate execution.

Sample code where these words are used:

  \ Some data size in kilobytes
 16 CONSTANT size
 
 \ Print a report on the conversion of kilobytes to bytes
 : report (-)
    size.  . "kilobytes equivalent"
    [size 1024 *] LITERAL.  . "bytes"
 ;

One of the constant topics of controversy surrounding the Fort language is the place it occupies among the "classical" imperative languages. Programs at Fort have an extremely unusual appearance:

• The program consists of an unusual sequence of words, among which there are no so-called "key" words that are recognized and processed in other programming languages ​​in a special way.
  With the release of the Star Wars movie series, a joke appeared on this occasion that has now become classic, which illustrates this feature of Fort well:

The mystery of Master Yoda's speech is open:
He was an old programmer at Fort ...

Original text

The mistery of Yoda's speech uncovered is:
Just an old Forth programmer Yoda was. ^[eleven]

• The above example at the same time points to a unique feature of Fort: the lack of a list of parameters in brackets and the ability to program in the native language. Using the vocabulary constructions of the native language allows you to make the program understandable, which increases its reliability .
• " Reverse Polish notation " of arithmetic expressions and the presence of several stacks.
• The dual nature of the Fort compiler. It cannot be stated unambiguously whether Fort is a compiler or interpreter. Almost always, it can be used in two modes, with the exception of rare cases like “target compilation” (translation into machine code of a program for a system with a different architecture).
• Lack of type system . Like assembly languages , Fort has no built-in type system. There is no way to find out what is at the top of the stack — a signed number, an unsigned number, a pointer to a string, a character, or two numbers considered as one long number. Type control is the responsibility of the programmer. In this case, special sets of words are used (for example, writing and reading memory cells is done with the words ! And @ , and characters with the words C! And C@ ), some entities are put into special stacks (for example, a stack of floating point numbers, according to the ANSI FORTH standard 94; it may or may not be implemented using the main stack).

These features determine the advantages and disadvantages of the Fort language:

• An experienced programmer familiar with the command system and processor architecture can write the “core” of a fort system in a few days.
• The freedom afforded to the programmer requires strong self-control. The entry threshold for Fort programming is lower than that of classical programming languages, but it requires getting used to and understanding not only the capabilities and features of Fort syntax, but also an understanding of the philosophy underlying it.
• Fort does not support any programming paradigm and supports them all at the same time. Writing a set of words for organizing OOP in a Fort program (and there may be several at the same time and they will coexist perfectly together) is much easier than deciding what features are required from this set of words.
• Dividing the program into many small words allows you to easily and quickly check them individually, passing them the necessary sets of input parameters and controlling what remains on the stack. In fact, this means that to test some component of the program, you do not have to download all the dependent components as a whole.
• Most Fort implementations allow you to decompile a program. The resulting text differs little from the original.
• Fort allows you to implement any programming technology available in other languages ​​and systems. It also admits tricks prohibited in other languages ​​(for example, self-modification of a code). The elimination of the negative consequences of these techniques by creating the right vocabulary that stimulates a competent methodology for their use is also the responsibility of the programmer.
• The size of the Fort code for 16-bit systems, with proper writing of the program, is sometimes 10-20 times smaller than the code compiled from the C program. For 32-bit systems, this gap is even greater. In operating systems, the total gain may already be hundreds or even thousands of times. The reason is very simple - the finished task at Fort has a size of several bytes, all auxiliary routines are implemented in the form of definitions available to everyone. The system on the Fort will fit into the processor, into which other systems are basically incapable of getting into.
• Synchronizing processes and threads in multi-tasking systems, switching contexts, accessing limited resources are the most difficult problems when writing an OS. To support these capabilities, special teams are even created in microprocessors. For the interpreter, this is not a problem at all, since it emulates any processor and any necessary command.

It is possible that, in fact, the “heavy legacy” that came from machines with low capabilities for which it was originally created hindered the development of the Fort most of all. In the ANSI FORTH 94 standard, for example, the following features exist:

• A portable program should assume that a stack of floating point numbers can be implemented using the main stack. Fortunately, for most modern compilers this is not the case. But the fact of the presence of such a clause in the standard creates certain inconveniences. When programming with the active use of floating-point arithmetic, this standard of the standard is traditionally ignored.
• A similar norm exists with respect to the control flow stack. Everything is not so simple here, as often this is exactly the case - during compilation the stack is used by the compiler. In the vast majority of cases, this has no effect on the program, but you need to remember about the feature itself. For example, if you want to compute some number outside the beginning of the definition in the compilation process, and then insert it into the word as a constant, then you need to use some workaround.
• The definitions of many words in the standard are too low-level. For example, the word 2* does not multiply by two, as its name implies, but “shifts the number by one bit to the most significant binary bit, filling the least significant bit with zero”. Of course, on most modern machines - this is one and the same, but the fact of using the features of a particular architecture is alarming. (There are also more obvious standard words for bit shifting - LSHIFT and RSHIFT .)

Many of these features are a consequence of the fact that at the time of adoption of the standard there were many poorly compatible Fort systems that were based on two partially different standards of 1979 and 1983.

• Forth language implementations
• Language Oriented Programming
• Stack
• Call stack
• Stack language
• Fortran

Dialects

• colorForth
• Factor (programming language)

Applications

• Axiom development kit

• Baranov S.N., Kolodin M. Yu. Phenomenon of fort // System informatics. - Novosibirsk: VO Nauka. Siberian Publishing Firm, 1995. - Vol. 4 . - S. 193-291 . - ISBN 5-02-030678-9 .
• Baranov S.N., Nozdrunov N.R. Language Fort and its implementation. - L .: Engineering, 1988 .-- 157 p. - (computers in production). - 100,000 copies. - ISBN 5-217-00324-3 .
• Leo Brodie. Thinking Forth . - ISBN 0-9764587-0-5 .
• Brody L. Starting Fort Programming Course = Starting Forth. An introduction to the Forth language and operating system for beginners and professionals / Per. from English; foreword I.V. Romanovsky. - M .: Finance and statistics, 1990. - 352 p. - 40,000 copies. - ISBN 5-279-00252-6 .
• Brody L. Way of Thinking - Fort .
• Burago A. Yu., Kirillin V.A., Romanovsky I.V. Fort - language for microprocessors. - Society “Knowledge”, Leningrad organization, 1989. - 36 p. - (To help the lecturer). - 26,000 copies.
• Dyakonov V.P. Fort-system for programming personal computers. - M .: Nauka, 1992 .-- 352 p. - ISBN 5-02-014460-6 .
• Kelly M., Spice N. Fort programming language / Per. from English - M .: Radio and communications, 1993 .-- 320 p. - ISBN 5-256-00438-7 .
• Semenov Yu. A. Programming in the Fort language. - M .: Radio and communications. - 240 p. - 50,000 copies. - ISBN 5-256-00547-2 .
• Townsend K., Foht D. Design and software implementation of expert systems on personal computers / Per. from English V.A. Kondratenko, S.V. Trubitsyna. - M .: Finance and statistics, 1990. - 320 p. - ISBN 5-279-00255-0 (USSR) ISBN 0-8306-2692-1 (USA).

Journal publications

• Stephen Pelc. Modern Forth // Dr. Dobb's Journal . - 2008, September.

• Forth Interst Group website
• Forth Inc. website (eng.)
• EuroFort Conference, there are all reports
• Google group

Standard

• Russian translation of the ANS FORTH 94 standard (made by Sergey Kadochnikov, several errors are known in this translation, for example, in the description of the word SEARCH)

Russian-speaking resources

• Site of Russian-speaking users of the Forth language
• Active Fort Language Forum on winglion
• Active Fort language forum on msyst
• Active Fort Language Forum at www.wrk.ru
• fido7.su.forth
• History of the Fort language (Russian)
• Fort Language Ideas (from eserv)
• Website A. Larionov

Fort Resource Link Collections

• Fort Wiki
• A collection of links to Fort resources at sourceforge.net