Editing Forth (programming language) (section)

==Facilities==
Forth's [[Formal grammar|grammar]] has no official specification. Instead, it is defined by a simple algorithm. The interpreter reads a line of input from the user input device, which is then parsed for a word using spaces as a [[delimiter]]; some systems recognise additional [[Whitespace character|whitespace]] characters. When the interpreter finds a word, it looks the word up in the ''dictionary''. If the word is found, the interpreter executes the code associated with the word, and then returns to parse the rest of the input stream. If the word isn't found, the word is assumed to be a number and an attempt is made to convert it into a number and push it on the stack; if successful, the interpreter continues parsing the input stream. Otherwise, if both the lookup and the number conversion fail, the interpreter prints the word followed by an error message indicating that the word is not recognised, flushes the input stream, and waits for new user input.<ref name="6dQ7P">{{harvnb|Brodie|1987|p=14}}</ref>

The definition of a new word is started with the word <code>:</code> (colon) and ends with the word <code>;</code> (semi-colon). For example,
<syntaxhighlight lang="forth">
 : X DUP 1+ . . ;
</syntaxhighlight>
will compile the word <code>X</code>, and makes the name findable in the dictionary. When executed by typing <code>10 X</code> at the console this will print <code>11 10</code>.<ref name="compiler">{{harvnb|Brodie|1987|p=16}}</ref>

Most Forth systems include an [[Assembly language#Assembler|assembler]] to write words using the processor's facilities. Forth assemblers often use a reverse Polish syntax in which the parameters of an instruction precede the instruction. A typical reverse Polish assembler prepares the operands on the stack and the mnemonic copies the whole instruction into memory as the last step. A Forth assembler is by nature a macro assembler, so that it is easy to define an alias for registers according to their role in the Forth system: e.g. "dsp" for the register used as the data stack pointer.<ref name="NAFQu">{{cite web | last = Rodriguez | first = Brad | url = https://www.bradrodriguez.com/papers/6809asm.txt | title = Build Your Own Assembler, Part 2: a 6809 Forth Assembler | access-date = 2023-04-29}}</ref>

=== Operating system, files, and multitasking ===
Most Forth systems run under a host operating system such as [[Microsoft Windows]], [[Linux]] or a version of [[Unix]] and use the host operating system's file system for source and data files; the ANSI Forth Standard describes the words used for I/O. All modern Forth systems use normal text files for source, even if they are embedded. An embedded system with a resident compiler gets its source via a serial line.

Classic Forth systems traditionally use neither [[operating system]] nor [[file system]]. Instead of storing code in files, source code is stored in disk blocks written to physical disk addresses. The word <code>BLOCK</code> is employed to translate the number of a 1K-sized block of disk space into the address of a buffer containing the data, which is managed automatically by the Forth system. Block use has become rare since the mid-1990s. In a hosted system those blocks too are allocated in a normal file in any case.

[[Computer multitasking|Multitasking]], most commonly [[Computer multitasking#Cooperative multitasking/time-sharing|cooperative]] [[round-robin scheduling]], is normally available (although multitasking words and support are not covered by the ANSI Forth Standard). The word <code>PAUSE</code> is used to save the current task's execution context, to locate the next task, and restore its execution context. Each task has its own stacks, private copies of some control variables and a scratch area. Swapping tasks is simple and efficient; as a result, Forth multitaskers are available even on very simple [[microcontroller]]s, such as the [[Intel MCS-51|Intel 8051]], [[Atmel AVR]], and [[TI MSP430]].<ref name="nxtDb">{{cite web | last = Rodriguez | first = Brad | url = https://www.bradrodriguez.com/papers/8051task.pdf | title = Multitasking 8051 CamelForth | access-date = 2023-04-29}}</ref>

Other non-standard facilities include a mechanism for issuing [[system call|call]]s to the host OS or [[windowing system]]s, and many provide extensions that employ the scheduling provided by the operating system. Typically they have a larger and different set of words from the stand-alone Forth's <code>PAUSE</code> word for task creation, suspension, destruction and modification of priority.

=== Self-compilation and cross compilation ===
A full-featured Forth system with all source code will compile itself, a technique commonly called meta-compilation or [[Self-hosting (compilers)|self-hosting]], by Forth programmers (although the term doesn't exactly match [[Meta-Compilation|meta-compilation]] as it is normally defined). The usual method is to redefine the handful of words that place compiled bits into memory. The compiler's words use specially named versions of fetch and store that can be redirected to a buffer area in memory. The buffer area simulates or accesses a memory area beginning at a different address than the code buffer. Such compilers define words to access both the target computer's memory, and the host (compiling) computer's memory.<ref name="Swdke">{{cite web |last=Rodriguez |first=Brad |date=July–August 1995 |url=https://www.bradrodriguez.com/papers/moving8.htm |title=MOVING FORTH, Part 8: CamelForth for the 6809 |access-date=2023-04-29}}</ref>

After the fetch and store operations are redefined for the code space, the compiler, assembler, etc. are recompiled using the new definitions of fetch and store. This effectively reuses all the code of the compiler and interpreter. Then, the Forth system's code is compiled, but this version is stored in the buffer. The buffer in memory is written to disk, and ways are provided to load it temporarily into memory for testing. When the new version appears to work, it is written over the previous version.

Numerous variations of such compilers exist for different environments. For [[embedded system]]s, the code may instead be written to another computer, a technique known as [[Cross-compilation|cross compilation]], over a serial port or even a single [[Transistor-transistor logic|TTL]] bit, while keeping the word names and other non-executing parts of the dictionary in the original compiling computer. The minimum definitions for such a Forth compiler are the words that fetch and store a byte, and the word that commands a Forth word to be executed. Often the most time-consuming part of writing a remote port is constructing the initial program to implement fetch, store and execute, but many modern microprocessors have integrated debugging features (such as the [[Motorola CPU32]]) that eliminate this task.<ref name="E5iFy">{{cite web | last = Shoebridge | first = Peter | date = 1998-12-21 | url = http://www.zeecube.com/archive/bdm/index.htm | title = Motorola Background Debugging Mode Driver for Windows NT | access-date = 2006-06-19 | url-status = dead | archive-url = https://web.archive.org/web/20070606083244/http://www.zeecube.com/archive/bdm/index.htm | archive-date = 2007-06-06}}</ref>