«previous next»

Implementation Features

SwiftForth is designed to produce optimal performance in a Windows 32-bit environment. This section describes the implementation of the Forth "virtual machine" in this context, and will be of interest to all experienced Forth users.

Execution model

SwiftForth is a 32-bit, subroutine-threaded Forth running as a GUI application under the Win32 subsystem the Microsoft Windows operating system.

"Subroutine threading" is an implementation strategy in which references in a colon definition are compiled as subroutine calls, rather than addresses that must be processed by an "address interpreter."

Colon and code definitions do not have a "code field" distinct from the content of the definition itself; data structures typically have a "code field" consisting of a call to the code for that data type. At the end of a colon definition, the conventional EXIT is replaced by a subroutine return.

The nature of a subroutine-threaded implementation lends itself to code inline expansion. SwiftForth takes advantage of this by having a header flag called INLINE, which indicates that a word is to be compiled inline or called. The compiler will automatically inline a definition whose INLINE field is set. Most of the kernel-level CODE words are so marked.

Register usage

Following are the register assignments:

EBX	top of stack
ESI	user area pointer
EDI	executable base address
EBP	data stack pointer
ESP	return stack pointer

All other registers are available for use without saving and restoring.

Note that the processor stack pointer is now used for the return stack; this is a consequence of the subroutine-threaded model. This model also does not require registers for the address interpreter; with more registers free, this system can use EBX to "cache" the top stack item, which further improves performance.

Memory model

SwiftForth runs in a single, contiguous, flat 32-bit address space in Windows virtual memory. SwiftForth is position-independent, which means it can run wherever Windows has instantiated it without having to keep track of where that is.

(In contrast, most Windows Forths keep the absolute address of the run-time memory space in a register, and internally use absolute addresses assigned from a zero base. When an address is passed to Windows, the register value must be added to the internal address; when Windows passes it an address, the register value must be subtracted to get the internal address.)

By being position-independent, SwiftForth simplifies and speeds up all Windows interactions. This feature is a natural consequence of subroutine-threading, since 80x86 calls use relative addresses. Forth "execution tokens" are zero-relative to the start of the run-time memory space, but they are used only internally and, thus, never need conversion. All data objects that return addresses return full absolute addresses that can be passed to Windows, if desired, without conversion.

Automatic WINCON resolution of Windows constants

Windows programming uses a large number of named constants, such as GENERIC_READ. The system would be burdened to include all of these as Forth entities. A link to the WINCON.DLL file is implemented and the dictionary search mechanism is extended to include it if the parsed text is not a known word or a valid number.

«previous next»