Forth Programmer’s Handbook

a token, such as an index into a table, which is more compact than an absolute address. Token threading is a key element in MacForth. In other respects, such an implementation resembles an indirect-threaded model.

!An additional implementation strategy that may be combined with any of the above VM implementations supports segmented architectures. For example, the 80x86 family supports segmented address spaces. Some Forth systems take advantage of this to enable a 16-bit system to support programs larger than 64K, by using different segments for dictionary, data space, stacks, etc.

References :, Section 4.2.4

Compiling words and literals, Section 4.3

1.2 FORTH OPERATING SYSTEM FEATURES

Many Forth products are based on a multitasking executive; some are multi-user as well. Some implementations run in a fully standalone mode, in which Forth provides all drivers for the hardware attached to the system. Other versions of Forth run in a co-resident mode, with a host operating system such as Windows.

In the latter case, the drivers that supply I/O services for peripherals such as disk and terminals do so by issuing calls to the host system. Although co-resi- dent systems may be somewhat slower than the standalone versions, they offer full file compatibility with the host OS, and usually are more flexible in hardware configuration. Co-resident versions of Forth usually offer all the system-level features of the native systems (including, in some cases, multiuser support on otherwise single-user systems such as MS-DOS), plus added commands for interacting with the host OS; the latter are documented in the system’s product documentation.

Disk I/O is handled by Forth systems in different ways, depending on the system environment. Many systems use standard blocks of 1024 bytes. This fixed block size applies both to Forth source program text and to data used by Forth programs. This standard format allows I/O on different media with different physical sector or record sizes, or even on different operating systems, to be handled by one standard block handler. Forth systems in a Windows or Macintosh environment access disk using a file-based system. Blocks and files are discussed further in Section 3.4 and Section 3.5, respectively. Also see your

Introduction 17

Forth Programmer’s Handbook

product documentation for details.

Forth makes it easy to control multiple tasks, either asynchronous background tasks or independent terminal service tasks. A small set of commands controls the multitasking facility. The limit on the number of tasks in the system is usually set by memory size. Since Forth definitions are naturally re-entrant, tasks rarely require much memory.

A terminal task has associated hardware that allows it to perform text input and output. Each terminal task has a partition that contains its stacks, private (or user) variable area, a scratch PAD (for text strings), and dictionary. A selected word list may be compiled into this partition to do a particular kind of processing which is a subset of the application but which is not available to other users.

A background task has a much smaller area, with only enough space for its stacks; there is no terminal associated with it, and it cannot perform text I/O. The routines the background task executes are located in a shared area or in the dictionary of one of the terminal tasks.

Forth normally runs with interrupts enabled. Interrupt vectors branch directly to the code which services the interrupting device, without any system intervention or overhead. The interrupt code is responsible for saving and restoring any registers it needs.

Interrupt code (actual assembler code) is responsible for performing any timecritical actions needed, such as reading a value from an analog device and storing it in a temporary location. The interrupt routine must also notify the task responsible for the device. Notification may take many forms, ranging from incrementing a counter, to “awakening” the task by storing in the task’s status area a pointer to code that will cause the task to become active the next time the task is available. Many interrupt handlers do nothing else.

Any processing which is not time-critical can be done by a task running a routine written in high-level Forth. In effect, the time-critical aspect of servicing an interrupt is decoupled from the more logically complex aspects of dealing with the consequences of the event signalled by the interrupt. Thus, it is guaranteed that interrupts will be serviced promptly, without having to wait for task scheduling, and yet as a programmer you have the convenience of using high-level Forth executed by the responding task for the main logic of the application.

18 Introduction