Forth Programmer’s Handbook

1.1.6 Numeric Input

The word >NUMBER is used by the text interpreter to convert strings of ASCII numerals and punctuation into binary integers that are pushed onto the stack. If there is no punctuation (except for an optional leading minus sign), a string of valid numerals is converted as a single-cell number, regardless of length. If a string of valid numerals is terminated by a decimal point, the text interpreter will convert it to a double-cell (double-precision) number regardless of length, occupying two data stack locations (high order part on top).

On eight-bit and 16-bit systems, a single-precision integer is 16 bits wide, and a double-precision integer is 32 bits wide. On 32-bit systems, these widths are 32 and 64 bits, respectively. On systems with optional floating-point routines, valid numeric strings containing an E or e (for exponent) will be converted as a floating-point number occupying one floating-point stack location (see Section 3.8 in this book and your product documentation for details).

Table 1: Integer precision and CPU data width

Some Forth systems will interpret any number containing embedded punctuation (see below) as a double-precision integer. Single-precision numbers are recognized by their lack of special punctuation. Conversions operate on character strings of the following format:

[ - ] dddd [ punctuation ] dddd … delimiter

where dddd is one or more valid digits according to the current base or radix in effect for the user. The user variable BASE is always used as the radix. All numeric strings must be ended by a blank or a carriage return. If another character is encountered—i.e., a character which is neither a valid digit in the current base, nor punctuation, nor whitespace characters (see glossary)—an abort will occur. There must be no spaces within the number, since a space is a delimiter.

Introduction 13

Forth Programmer’s Handbook

On systems allowing embedded punctuation, the characters shown in Table 2 may appear in a number. A leading minus sign, if present, must immediately precede the first digit or punctuation character.

Table 2: Valid numeric punctuation characters

All punctuation characters are functionally equivalent, including the period (decimal point). The punctuation performs no other function than to set a flag that indicates its presence. On some systems, a punctuation character also causes the digits that follow it to be counted, with the count available to subsequent number-conversion words. Multiple punctuation characters may be contained in a single number; the following character strings would both convert to the same double-precision integer 123456:

1234.56

12,345.6

14 Introduction

Forth Programmer’s Handbook

References Use of the text interpreter for number input, Section 4.1.4 Floating point input, Section 3.8.2

1.1.7 Two-stack Virtual Machine

A running Forth system presents to the programmer a virtual machine (VM), like a processor. It has two push-down stacks, code and data space, an “ALU” that executes instructions, and several registers. Previous sections briefly discuss the stacks and some aspects of memory use in Forth; this section will describe some features of the virtual machine as a processor.

A number of approaches to implementing the Forth VM have been developed over the years. Each has features that optimize the VM for the physical CPU on which it runs, for its intended use, or for some combination of these. We will discuss the most common implementation strategies.

The function of the Forth VM, like that of most processors, is to execute instructions. Two of the VM’s registers are used to manage the stacks. Others control execution in various ways. Various implementations name and use these registers differently; for purposes of discussion in this book, we will use the names in Table 3.

Table 3: Registers in the Forth virtual machine

A standard Forth high-level, or colon, definition consists fundamentally of a

Introduction 15

Forth Programmer’s Handbook

name followed by a number of references to previously defined words. When such a definition is invoked by a call to its name, the run-time code needs to manage the execution, in sequence, of the words making up the body of the definition. Exactly how this is done depends on the particular system and the method it uses to implement the Forth virtual machine. The implementation strategy used affects how definitions are structured and how they are executed. See the relevant product documentation for the method used in your system. There are several possibilities:

!Indirect-threaded code. This was the original design, and remains the most common method. Pointers to previously defined words are compiled into the executing word’s parameter field. The code field of the executing word contains a pointer to machine code for an address interpreter, which sequentially executes those definitions by performing indirect jumps through register I, which is used to keep its place. When a definition calls another high-level definition, the current I is pushed onto the return stack; when the called definition finishes, the saved I is popped off of the return stack. This process is analogous to subroutine calls, and I in this model is analogous to a physical processor’s instruction pointer.

!Direct-threaded code. In this model, the code field contains the actual machine code for the address interpreter, instead of a pointer to it. This is somewhat faster, but takes more memory for some classes of words. For this reason, it is most prevalent on 32-bit systems.

!Subroutine-threaded code. In this model, for each referenced definition in the executing word, the compiler places an in-line, jump-to-subroutine instruction with the destination address. On a 16-bit system, this technique costs extra bytes for each compiled reference. This approach is an enabling technique to allow a progression to native code generation. In this model, the underlying processor’s instruction pointer is used as Forth’s I (which usually is not a named register in such implementations).

!Native code generation. Going one step beyond subroutine-threaded code, this technique generates in-line machine instructions for simple primitives such as +, and uses jumps to other high-level routines. The result can run much faster, at the cost of size and compiler complexity. Native code can also be more difficult to debug than threaded code. This technique is characteristic of optimized systems for native Forth CPUs such as the RTX, and for 32-bit systems, where code compactness is often less critical than speed.

!Token threading. This technique compiles references to other words by using

16 Introduction