6140 lines
196 KiB
Plaintext
6140 lines
196 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
FORTH-83 STANDARD
|
||
|
||
A PUBLICATION OF THE FORTH STANDARDS TEAM
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
AUGUST 1983
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
FORTH-83 STANDARD
|
||
|
||
|
||
|
||
|
||
COPYRIGHT c. 1983 FORTH STANDARDS TEAM
|
||
|
||
Permission is hereby granted to reproduce this document in whole
|
||
or in part provided that such reproductions refer to the fact
|
||
that the copied material is subject to copyright by the FORTH
|
||
Standards Team. No changes or modifications may be made to the
|
||
copied material unless it is clearly indicated that such changes
|
||
were not incorporated in the original copyrighted work.
|
||
|
||
The existence of a FORTH Standard does not in any respect
|
||
preclude anyone, whether the individual has approved this
|
||
Standard or not, from implementing, marketing, purchasing or
|
||
using products, processes, or procedures not conforming to the
|
||
Standard. FORTH Standards are subject to periodic review and
|
||
users are cautioned to obtain the latest editions.
|
||
|
||
ISBN 0-914699-03-2
|
||
|
||
FORTH STANDARDS TEAM
|
||
P.O. BOX 4545
|
||
MOUNTAIN VIEW, CA 94040
|
||
USA
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ii
|
||
|
||
|
||
|
||
|
||
|
||
FORTH-83 STANDARD
|
||
|
||
|
||
|
||
|
||
TABLE OF CONTENTS
|
||
|
||
1. FOREWORD ............................................... 1
|
||
2. PURPOSE ................................................ 2
|
||
3. SCOPE .................................................. 2
|
||
4. TRADEOFFS .............................................. 3
|
||
5. DEFINITIONS OF TERMS ................................... 4
|
||
6. REFERENCES ............................................. 12
|
||
7. REQUIREMENTS ........................................... 13
|
||
8. COMPLIANCE AND LABELING ................................ 15
|
||
9. USAGE .................................................. 17
|
||
10. ERROR CONDITIONS ....................................... 20
|
||
11. GLOSSARY NOTATION ...................................... 22
|
||
12. REQUIRED WORD SET ...................................... 25
|
||
13. DOUBLE NUMBER EXTENSION WORD SET ....................... 41
|
||
14. ASSEMBLER EXTENSION WORD SET ........................... 44
|
||
15. SYSTEM EXTENSION WORD SET .............................. 46
|
||
16. CONTROLLED REFERENCE WORDS ............................. 48
|
||
|
||
APPENDICES
|
||
A. FORTH STANDARDS TEAM MEMBERSHIP ................... 51
|
||
B. UNCONTROLLED REFERENCE WORDS ...................... 54
|
||
C. EXPERIMENTAL PROPOSALS ............................ 60
|
||
C.1 SEARCH ORDER SPECIFICATION AND CONTROL ....... 61
|
||
C.2 DEFINITION FIELD ADDRESS CONVERSION OPERATORS . 66
|
||
D. STANDARDS TEAM CHARTER ............................ 69
|
||
E. PROPOSAL/COMMENT FORM AND INSTRUCTIONS ............ 78
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
iii
|
||
|
||
|
||
|
||
|
||
|
||
FORTH-83 STANDARD
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
iv
|
||
|
||
|
||
|
||
|
||
|
||
1. FOREWORD
|
||
|
||
|
||
|
||
|
||
1. FOREWORD
|
||
|
||
|
||
FORTH is an integrated programming approach and computer
|
||
language. FORTH was invented by Mr. Charles Moore specifically
|
||
to increase programmer productivity in the development of
|
||
computer related applications without sacrificing machine
|
||
efficiency. FORTH is a layered environment containing the
|
||
elements of a computer language as well as those of an operating
|
||
system and a machine monitor. This extensible, layered
|
||
environment provides for highly interactive program development
|
||
and testing.
|
||
|
||
In the interests of transportability of application software
|
||
written in FORTH, standardization efforts began in the mid-1970s
|
||
by the European FORTH User's Group (EFUG). This effort resulted
|
||
in the FORTH-77 Standard. As the language continued to evolve,
|
||
an interim FORTH-78 Standard was published by the FORTH Standards
|
||
Team. Following FORTH Standards Team meetings in 1979 the FORTH-
|
||
79 Standard was published in 1980.
|
||
|
||
The FORTH Standards Team is comprised of individuals who have a
|
||
great variety of experience and technical expertise with FORTH.
|
||
The FORTH Standards Team consists of both users and implementers.
|
||
Comments, proposals, and correspondence should be mailed to:
|
||
FORTH Standards Team, P.O. Box 4545, Mountain View, CA 94040 USA.
|
||
|
||
FORTH's extensibility allows the language to be expanded and
|
||
adapted to special needs and different hardware systems. A
|
||
programmer or vendor may choose to strictly adhere with the
|
||
standard, but the choice to deviate is acknowledged as beneficial
|
||
and sometimes necessary. If the standard does not explicitly
|
||
specify a requirement or restriction, a system or application may
|
||
utilize any choice without sacrificing compliance to the standard
|
||
provided that the system or application remains transportable and
|
||
obeys the other requirements of the standard.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
1
|
||
|
||
|
||
|
||
|
||
|
||
2. PURPOSE
|
||
|
||
|
||
|
||
|
||
2. PURPOSE
|
||
|
||
|
||
The purpose of this standard is to allow transportability of
|
||
FORTH-83 Standard Programs in source form among FORTH-83 Standard
|
||
Systems. A standard program shall execute equivalently on all
|
||
standard systems.
|
||
|
||
|
||
|
||
3. SCOPE
|
||
|
||
|
||
This standard shall apply to any FORTH-83 Standard Program
|
||
executing on any FORTH-83 Standard System, provided sufficient
|
||
computer resources (memory, mass storage) are available.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2
|
||
|
||
|
||
|
||
|
||
|
||
4. TRADEOFFS
|
||
|
||
|
||
|
||
|
||
4. TRADEOFFS
|
||
|
||
|
||
When conflicting choices are made, the following order guides the
|
||
Standards Team:
|
||
|
||
1) Functional correctness - known bounds, non-ambiguous;
|
||
|
||
2) Portability - repeatable results when programs are
|
||
transported among Standard Systems;
|
||
|
||
3) Simplicity;
|
||
|
||
4) Naming clarity - uniformity of expression using descriptive
|
||
rather than procedure names, i.e., [COMPILE] rather than 'C,
|
||
and ALLOT rather than DP+! ;
|
||
|
||
5) Generality;
|
||
|
||
6) Execution speed;
|
||
|
||
7) Memory compactness;
|
||
|
||
8) Compilation speed;
|
||
|
||
9) Historical continuity;
|
||
|
||
10) Pronounceability;
|
||
|
||
11) Teachability.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
3
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
These are the definitions of the terms used within this Standard.
|
||
|
||
address, byte
|
||
An unsigned 16-bit number that locates an 8-bit byte in a
|
||
standard FORTH address space over the range {0..65,535}. It
|
||
may be a native machine address or a representation on a
|
||
virtual machine, locating the addr-th byte within the
|
||
virtual byte address space. Addresses are treated as
|
||
unsigned numbers. See: "arithmetic, two's complement"
|
||
|
||
address, compilation
|
||
The numerical value compiled for a FORTH word definition
|
||
which identifies that definition. The address interpreter
|
||
uses this value to locate the machine code corresponding to
|
||
each definition.
|
||
|
||
address, native machine
|
||
The natural address representation of the host computer.
|
||
|
||
address, parameter field
|
||
The address of the first byte of memory associated with a
|
||
word definition for the storage of compilation addresses (in
|
||
a colon definition), numeric data, text characters, etc.
|
||
|
||
arithmetic, two's complement
|
||
Arithmetic is performed using two's complement integers
|
||
within a field of either 16 or 32 bits as indicated by the
|
||
operation. Addition and subtraction of two's complement
|
||
integers ignore any overflow condition. This allows numbers
|
||
treated as unsigned to produce the same results as if the
|
||
numbers had been treated as signed.
|
||
|
||
block
|
||
The 1024 bytes of data from mass storage which are
|
||
referenced by block numbers in the range {0..the number of
|
||
blocks available -1}. The actual amount of data transferred
|
||
and the translation from block number to device and physical
|
||
record is a function of the implementation. See: "block
|
||
buffer" "mass storage"
|
||
|
||
block buffer
|
||
A 1024-byte memory area where a block is made temporarily
|
||
available for use. Block buffers are uniquely assigned to
|
||
blocks. See: "9.7 Multiprogramming Impact"
|
||
|
||
byte
|
||
An assembly of 8 bits. In reference to memory, it is the
|
||
storage capacity for 8 bits.
|
||
|
||
|
||
|
||
|
||
4
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
character
|
||
A 7-bit number the significance of which is given by the
|
||
ASCII standard. When contained in a larger field, the
|
||
higher order bits are zero. See: "6. REFERENCES"
|
||
|
||
compilation
|
||
The action of converting text words from the input stream
|
||
into an internal form suitable for later execution. When in
|
||
the compile state, the compilation addresses of FORTH words
|
||
are compiled into the dictionary for later execution by the
|
||
address interpreter. Numbers are compiled to be placed on
|
||
the data stack when later executed. Numbers are accepted
|
||
from the input stream unsigned or negatively signed and
|
||
converted using the value of BASE . See: "number" "number
|
||
conversion" "interpreter, text"
|
||
|
||
defining word
|
||
A word that, when executed, creates a new dictionary entry
|
||
in the compilation vocabulary. The new word name is taken
|
||
from the input stream. If the input stream is exhausted
|
||
before the new name is available, an error condition exists.
|
||
Example of defining words are: : CONSTANT CREATE
|
||
|
||
definition
|
||
See: "word definition"
|
||
|
||
dictionary
|
||
A structure of word definitions in computer memory which is
|
||
extensible and grows toward higher memory addresses.
|
||
Entries are organized in vocabularies to aid location by
|
||
name. See: "search order"
|
||
|
||
display
|
||
The process of sending one or more characters to the current
|
||
output device. These characters are typically displayed or
|
||
printed on a terminal. The selection of the current output
|
||
device is system dependent.
|
||
|
||
division, floored
|
||
Integer division in which the remainder carries the sign of
|
||
the divisor or is zero, and the quotient is rounded to its
|
||
arithmetic floor. Note that, except for error conditions,
|
||
n1 n2 SWAP OVER /MOD ROT * + is identical to n1. See:
|
||
"floor, arithmetic"
|
||
Examples:
|
||
dividend divisor remainder quotient
|
||
10 7 3 1
|
||
-10 7 4 -2
|
||
10 -7 -4 -2
|
||
-10 -7 -3 1
|
||
|
||
equivalent execution
|
||
|
||
|
||
|
||
|
||
|
||
5
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
A standard program will produce the same results, exclusive
|
||
of timing dependencies, when given the same inputs on any
|
||
Standard System which has sufficient resources to execute
|
||
the program. Only standard source programs are
|
||
transportable.
|
||
|
||
error condition
|
||
An exceptional condition which requires action by the system
|
||
which may be other than the expected function. Refer to the
|
||
section "10. Error Conditions".
|
||
|
||
false
|
||
A zero number represents the false state of a flag.
|
||
|
||
flag
|
||
A number that may have one of two logical states, false or
|
||
true. See: "false" "true"
|
||
|
||
floor, arithmetic
|
||
If z is any real number, then the floor of z is the greatest
|
||
integer less than or equal to z.
|
||
The floor of +.6 is 0
|
||
The floor of -.4 is -1
|
||
|
||
free field format
|
||
Numbers are converted using the value of BASE and then
|
||
displayed with no leading zeros. A trailing space is
|
||
displayed. The number of characters displayed is the
|
||
minimum number of characters, at least one, to uniquely
|
||
represent the number. See: "number conversion"
|
||
|
||
glossary
|
||
A set of explanations in natural language to describe the
|
||
corresponding computer execution of word definitions.
|
||
|
||
immediate word
|
||
A word which executes when encountered during compilation or
|
||
interpretation. Immediate words handle special cases during
|
||
compilation. See, for example, IF LITERAL ." etc.
|
||
|
||
input stream
|
||
A sequence of characters available to the system, for
|
||
processing by the text interpreter. The input stream
|
||
conventionally may be taken from the current input device
|
||
(via the text input buffer) and mass storage (via a block
|
||
buffer). BLK , >IN , TIB and #TIB specify the input stream.
|
||
Words using or altering BLK , >IN , TIB and #TIB are
|
||
responsible for maintaining and restoring control of the
|
||
input stream.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
6
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
The input stream extends from the offset value of >IN to the
|
||
size of the input stream. If BLK is zero the input stream
|
||
is contained within the area addressed by TIB and is #TIB
|
||
bytes long. If BLK is non-zero the input stream is
|
||
contained within the block buffer specified by BLK and is
|
||
1024 bytes long. See: "11.8 Input Text"
|
||
|
||
interpreter, address
|
||
The machine code instructions, routine or other facilities
|
||
that execute compiled word definitions containing
|
||
compilation addresses.
|
||
|
||
interpreter, text
|
||
The word definitions(s) that repeatedly accepts a word name
|
||
from the input stream, locates the corresponding compilation
|
||
address and starts the address interpreter to execute it.
|
||
Text from the input stream interpreted as a number leaves
|
||
the corresponding value on the data stack. Numbers are
|
||
accepted from the input stream unsigned or negatively signed
|
||
and converted using the value of BASE . See: "number"
|
||
"number conversion"
|
||
|
||
layers
|
||
The grouping of word names of each Standard word set to show
|
||
like characteristics. No implementation requirements are
|
||
implied by this grouping.
|
||
|
||
layer, compiler
|
||
Word definitions which add new procedures to the dictionary
|
||
or which aid compilation by adding compilation addresses or
|
||
data structures to the dictionary.
|
||
|
||
layer, devices
|
||
Word definitions which allow access to mass storage and
|
||
computer peripheral devices.
|
||
|
||
layer, interpreter
|
||
Word definitions which support vocabularies, terminal
|
||
output, and the interpretation of text from the text input
|
||
buffer or a mass storage device by executing the
|
||
corresponding word definitions.
|
||
|
||
layer, nucleus
|
||
Word definitions generally defined in machine code that
|
||
control the execution of the fundamental operations of a
|
||
virtual FORTH machine. This includes the address
|
||
interpreter.
|
||
|
||
load
|
||
Redirection of the text interpreter's input stream to be
|
||
from mass storage. This is the general method for
|
||
compilation of new definitions into the dictionary.
|
||
|
||
mass storage
|
||
|
||
|
||
|
||
7
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
Storage which might reside outside FORTH's address space.
|
||
Mass storage data is made available in the form of 1024-byte
|
||
blocks. A block is accessible within the FORTH address
|
||
space in a block buffer. When a block has been indicated as
|
||
UPDATEed (modified) the block will ultimately be transferred
|
||
to mass storage.
|
||
|
||
number
|
||
When values exist within a larger field, the most-
|
||
significant bits are zero. 16-bit numbers are represented
|
||
in memory by addressing the first of two bytes at
|
||
consecutive addresses. The byte order is unspecified by
|
||
this Standard. Double numbers are represented on the stack
|
||
with the most-significant 16 bits (with sign) most
|
||
accessible. Double numbers are represented in memory by two
|
||
consecutive 16-bit numbers. The address of the least
|
||
significant 16 bits is two greater than the address of the
|
||
most significant 16 bits. The byte order within each 16-bit
|
||
field is unspecified. See: "arithmetic, two's complement"
|
||
"number types" "9.8 Numbers" "11.7 Stack Parameters"
|
||
|
||
number conversion
|
||
Numbers are maintained internally in binary and represented
|
||
externally by using graphic characters within the ASCII
|
||
character set. Conversion between the internal and external
|
||
forms is performed using the current value of BASE to
|
||
determine the digits of a number. A digit has a value
|
||
ranging from zero to the value of BASE-1. The digit with
|
||
the value zero is represented by the ASCII character "0"
|
||
(position 3/0 with the decimal equivalent of 48). This
|
||
representation of digits proceeds through the ASCII
|
||
character set to the character "(" corresponding to the
|
||
decimal value 9. For digits with a value exceeding 9, the
|
||
ASCII graphic characters beginning with the character "A"
|
||
(position 4/1 with the decimal equivalent 65) corresponding
|
||
to the decimal value 10 are used. This sequence then
|
||
continues up to and including the digit with the decimal
|
||
value 71 which is represented by the ASCII character "~"
|
||
(position 7/14 with a decimal equivalent 126). A negative
|
||
number may be represented by preceding the digits with a
|
||
single leading minus sign, the character "-".
|
||
|
||
number types
|
||
All number types consist of some number of bits. These bits
|
||
are either arbitrary or are weighted.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
8
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
Signed and unsigned numbers use weighted bits. Weighted
|
||
bits within a number have a value of a power of two
|
||
beginning with the rightmost (least-significant) bit having
|
||
the value of two to the zero power. This weighting
|
||
continues to the leftmost bit increasing the power by one
|
||
for each bit. For an unsigned number this weighting pattern
|
||
includes the leftmost bit; thus, for an unsigned 16-bit
|
||
number the weight of the leftmost bit is 32,768. For a
|
||
signed number this weighting pattern includes the leftmost
|
||
bit but the weight of the leftmost bit is negated; thus, for
|
||
a signed 16-bit number the weight of the leftmost bit is
|
||
-32,768. This weighting pattern for signed numbers is
|
||
called two's complement notation.
|
||
|
||
Unspecified weighted numbers are either unsigned numbers or
|
||
signed numbers; program context determines whether the
|
||
number is signed or unsigned. See: "11.7 Stack Parameters"
|
||
|
||
pictured numeric output
|
||
The use of numeric output definitions which convert
|
||
numerical values into text strings. These definitions are
|
||
used in a sequence which resembles a symbolic 'picture' of
|
||
the desired text format. Conversion proceeds from least-
|
||
significant digit to most-significant digit, and converted
|
||
characters are stored from higher memory addresses to lower.
|
||
|
||
program
|
||
A complete specification of execution to achieve a specific
|
||
function (application task) expressed in FORTH source code
|
||
form.
|
||
|
||
receive
|
||
The process of obtaining one character from the current
|
||
input device. The selection of the current input device is
|
||
system dependent.
|
||
|
||
recursion
|
||
The process of self-reference, either directly or
|
||
indirectly.
|
||
|
||
return
|
||
The means of indicating the end of text by striking a key on
|
||
an input device. The key used is system dependent. This
|
||
key is typically called "RETURN", "CARRIAGE RETURN", or
|
||
"ENTER".
|
||
|
||
screen
|
||
Textual data arranged for editing. By convention, a screen
|
||
consists of 16 lines (numbered 0 through 15) of 64
|
||
characters each. Screens usually contain program source
|
||
text, but may be used to view mass storage data. The first
|
||
byte of a screen occupies the first byte of a mass storage
|
||
block, which is the beginning point for text interpretation
|
||
during a load.
|
||
|
||
|
||
|
||
9
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
search order
|
||
A specification of the order in which selected vocabularies
|
||
in the dictionary are searched. Execution of a vocabulary
|
||
makes it the first vocabulary in the search order. The
|
||
dictionary is searched whenever a word is to be located by
|
||
its name. This order applies to all dictionary searches
|
||
unless otherwise noted. The search order begins with the
|
||
last vocabulary executed and ends with FORTH , unless
|
||
altered in a system dependent manner.
|
||
|
||
source definition
|
||
Text consisting of word names suitable for compilation or
|
||
execution by the text interpreter. Such text is usually
|
||
arranged in screens and maintained on a mass storage device.
|
||
|
||
stack, data
|
||
A last in, first out list consisting of 16-bit binary
|
||
values. This stack is primarily used to hold intermediate
|
||
values during execution of word definitions. Stack values
|
||
may represent numbers, characters, addresses, boolean
|
||
values, etc.
|
||
|
||
When the name 'stack' is used alone, it implies the data
|
||
stack.
|
||
|
||
stack, return
|
||
A last in, first out list which contains the addresses of
|
||
word definitions whose execution has not been completed by
|
||
the address interpreter. As a word definition passes
|
||
control to another definition, the return point is placed on
|
||
the return stack.
|
||
|
||
The return stack may cautiously be used for other values.
|
||
|
||
string, counted
|
||
A sequence of consecutive 8-bit bytes located in memory by
|
||
their low memory address. The byte at this address contains
|
||
a count {0..255} of the number of bytes following which are
|
||
part of the string. The count does not include the count
|
||
byte itself. Counted strings usually contain ASCII
|
||
characters.
|
||
|
||
string, text
|
||
A sequence of consecutive 8-bit bytes located in memory by
|
||
their low memory address and length in bytes. Strings
|
||
usually, but not exclusively, contain ASCII characters.
|
||
When the term 'string' is used alone or in conjunction with
|
||
other words it refers to text strings.
|
||
|
||
structure, control
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
10
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
A group of FORTH words which when executed alter the
|
||
execution sequence. The group starts and terminates with
|
||
compiler words. Examples of control structures: DO ...
|
||
LOOP DO ... +LOOP BEGIN ... WHILE ... REPEAT BEGIN ...
|
||
UNTIL IF ... THEN IF ... ELSE ... THEN See: "9.9 Control
|
||
Structures"
|
||
|
||
transportability
|
||
This term indicates that equivalent execution results when a
|
||
program is executed on other than the system on which it was
|
||
created. See: "equivalent execution"
|
||
|
||
true
|
||
A non-zero value represents the true state of a flag. Any
|
||
non-zero value will be accepted by a standard word as
|
||
'true'; all standard words return a 16-bit value with all
|
||
bits set to one when returning a 'true' flag.
|
||
|
||
user area
|
||
An area in memory which contains the storage for user
|
||
variable.
|
||
|
||
variable, user
|
||
A variable whose data storage area is usually located in the
|
||
user area. Some system variables are maintained in the user
|
||
area so that the words may be re-entrant to different users.
|
||
|
||
vocabulary
|
||
An ordered list of word definitions. Vocabularies are an
|
||
advantage in separating different word definitions that may
|
||
have the same name. More than one definition with the same
|
||
name can exist in one vocabulary. The latter is called a
|
||
redefinition. The most recently created redefinition will
|
||
be found when the vocabulary is searched.
|
||
|
||
vocabulary, compilation
|
||
The vocabulary into which new word definitions are appended.
|
||
|
||
word
|
||
A sequence of characters terminated by one blank or the end
|
||
of the input stream. Leading blanks are ignored. Words are
|
||
usually obtained via the input stream.
|
||
|
||
word definition
|
||
A named FORTH execution procedure compiled into the
|
||
dictionary. Its execution may be defined in terms of
|
||
machine code, as a sequence of compilation address, or other
|
||
compiled words.
|
||
|
||
word name
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
11
|
||
|
||
|
||
|
||
|
||
|
||
5. DEFINITIONS OF TERMS
|
||
|
||
|
||
The name of a word definition. Word names are limited to 31
|
||
characters and may not contain an ASCII space. If two
|
||
definitions have different word names in the same vocabulary
|
||
they must be uniquely findable when this vocabulary is
|
||
searched. See: "vocabulary" "9.5.3 EXPECT"
|
||
|
||
word set
|
||
A named group of FORTH word definitions in the Standard.
|
||
|
||
word set, assembler extension
|
||
Additional words which facilitate programming in the native
|
||
machine language of the computer which are by nature system
|
||
dependent.
|
||
|
||
word set, double number extension
|
||
Additional words which facilitate manipulation of 32-bit
|
||
numbers.
|
||
|
||
word set, required
|
||
The minimum words needed to compile and execute Standard
|
||
Programs.
|
||
|
||
word set, system extension
|
||
Additional words which facilitate the access to internal
|
||
system characteristics.
|
||
|
||
word, standard
|
||
A named FORTH procedure definition, in the Required word set
|
||
or any extension word sets, formally reviewed and accepted
|
||
by the Standards Team.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
12
|
||
|
||
|
||
|
||
|
||
|
||
6. REFERENCES
|
||
|
||
|
||
|
||
|
||
6. REFERENCES
|
||
|
||
|
||
The following document is considered to be a portion of this
|
||
Standard:
|
||
|
||
American National Standard Code for Information Interchange,
|
||
___________________________________________________________
|
||
X3.4-1977 (ASCII), American National Standards Institute,
|
||
1430 Broadway, New York, NY 10018, USA.
|
||
|
||
The following documents are noted as pertinent to the FORTH-83
|
||
Standard, but are not part of this Standard.
|
||
|
||
FORTH-77, FORTH Users Group, FST-780314
|
||
|
||
FORTH-78, FORTH International Standards Team
|
||
|
||
FORTH-79, FORTH Standards Team
|
||
|
||
FORTH-83 STANDARD, Appendices, FORTH Standards Team
|
||
|
||
Webster's Collegiate Dictionary shall be used to resolve
|
||
_______________________________
|
||
conflicts in spelling and English word usage.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
13
|
||
|
||
|
||
|
||
|
||
|
||
7. REQUIREMENTS
|
||
|
||
|
||
|
||
|
||
7. REQUIREMENTS
|
||
|
||
|
||
|
||
7.1 Documentation Requirements
|
||
|
||
|
||
7.1.1 Each Standard System shall be accompanied by a
|
||
statement of:
|
||
|
||
1. System dictionary space used in bytes;
|
||
|
||
2. Application dictionary space available in bytes;
|
||
|
||
3. Data space in bytes;
|
||
|
||
4. Return stack space in bytes;
|
||
|
||
5. Mass storage block ranges used by the system;
|
||
|
||
6. Mass storage block ranges available to applications;
|
||
|
||
7. Operator's terminal facilities available;
|
||
|
||
8. System action taken upon each of the general or specified
|
||
error conditions as identified in this standard.
|
||
|
||
|
||
7.1.2 Each standard program shall be accompanied by a
|
||
statement of the minimum requirements for:
|
||
|
||
1. Dictionary space in bytes;
|
||
|
||
2. Data stack space in bytes;
|
||
|
||
3. Return stack space in bytes;
|
||
|
||
4. Mass storage block ranges;
|
||
|
||
5. Operator's terminal facilities
|
||
|
||
|
||
7.2 Testing Requirements
|
||
|
||
The following host computer configuration is specified as a
|
||
minimum environment for testing against this Standard.
|
||
Applications may require different capacities.
|
||
|
||
1. 2000 bytes of memory for application dictionary;
|
||
|
||
2. Data stack of 64 bytes;
|
||
|
||
|
||
|
||
|
||
14
|
||
|
||
|
||
|
||
|
||
|
||
7. REQUIREMENTS
|
||
|
||
|
||
3. Return stack of 48 bytes;
|
||
|
||
4. Mass storage capacity of 32 blocks, numbered 0 through 31;
|
||
|
||
5. One ASCII input/output device acting as an operator's
|
||
terminal.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
15
|
||
|
||
|
||
|
||
|
||
|
||
8. COMPLIANCE AND LABELING
|
||
|
||
|
||
|
||
|
||
8. COMPLIANCE AND LABELING
|
||
|
||
|
||
The FORTH Standards Team hereby specifies the requirements for
|
||
labeling of systems and applications so that the conditions for
|
||
program portability may be established.
|
||
|
||
A Standard System may use the specified labeling if it complies
|
||
with the terms of this Standard and meets the particular Word Set
|
||
definitions.
|
||
|
||
A Standard Program (application) may use the specified labeling
|
||
if it utilizes the specified Standard System according to this
|
||
Standard and executes equivalently on any such system.
|
||
|
||
In a system or application, a standard word may not be redefined
|
||
to perform a different function within the vocabulary FORTH.
|
||
|
||
|
||
FORTH Standard
|
||
|
||
A system may be labeled:
|
||
|
||
FORTH-83 Standard
|
||
|
||
if it includes all of the Required Word Set in either source or
|
||
object form and complies with the text of this Standard. After
|
||
executing "FORTH-83" the dictionary must contain all of the
|
||
Required Word Set in the vocabulary FORTH, as specified in this
|
||
Standard.
|
||
|
||
|
||
Standard Sub-set
|
||
|
||
A system may be labeled:
|
||
|
||
FORTH-83 Standard Sub-set
|
||
|
||
if it includes a portion of the Required Word Set and complies
|
||
with the remaining text of this Standard. However, no Required
|
||
Word may be present with a non-standard definition.
|
||
|
||
|
||
Standard with Extensions
|
||
|
||
A system may be labeled:
|
||
|
||
FORTH-83 Standard with <name> Standard Extension(s)
|
||
|
||
if it comprises a FORTH-83 Standard System and one or more
|
||
Standard Extension Word Set(s). For example, a designation would
|
||
be in the form:
|
||
|
||
|
||
|
||
16
|
||
|
||
|
||
|
||
|
||
|
||
8. COMPLIANCE AND LABELING
|
||
|
||
|
||
FORTH-83 Standard with Double-Number Standard Extension
|
||
|
||
|
||
Standard Program
|
||
|
||
A FORTH source program which executes equivalently on any
|
||
Standard System may be labeled:
|
||
|
||
FORTH-83 Standard Program
|
||
|
||
See: "equivalent execution" "7. REQUIREMENTS"
|
||
|
||
|
||
Standard Program with Environmental Dependencies
|
||
|
||
A program which is standard in all ways except for specific
|
||
environmentally dependent words may be labeled:
|
||
|
||
FORTH-83 Standard Program with Environmental Dependencies
|
||
|
||
if the following additional requirements are met:
|
||
|
||
1) Environmental dependencies (including hardware
|
||
dependencies) shall be factored into an isolated set of
|
||
application word definitions.
|
||
|
||
2) Each environmentally dependent word definition must be
|
||
fully documented, including all dependencies in a manner at
|
||
least as detailed as the standard words.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
17
|
||
|
||
|
||
|
||
|
||
|
||
9. USAGE
|
||
|
||
|
||
|
||
|
||
9. USAGE
|
||
|
||
|
||
|
||
9.1 Words Names and Word Definitions
|
||
|
||
A Standard Program may reference only the definitions of the
|
||
Required Word Set and Standard Extensions and definitions which
|
||
are subsequently defined in terms of these words. Furthermore, A
|
||
Standard Program must use the standard words as required by any
|
||
conventions of this Standard. Equivalent execution must result
|
||
from Standard Programs.
|
||
|
||
The implementation of a Standard System may use words and
|
||
techniques outside the scope of the Standard, provided that no
|
||
program running on that system is required to use words outside
|
||
the Standard for normal operation.
|
||
|
||
If a Standard System or Standard Program redefines Standard
|
||
definitions within the FORTH vocabulary, these definitions must
|
||
comply with the Standard.
|
||
|
||
|
||
9.2 Addressable Memory
|
||
|
||
The FORTH system may share the dictionary space with the user's
|
||
application. The native addressing protocol of the host computer
|
||
is beyond the scope of this Standard.
|
||
|
||
Therefore, in a Standard Program, the user may only operate on
|
||
data which was stored by the application. No exceptions!
|
||
|
||
A Standard Program may address:
|
||
|
||
1. parameter fields of words created with CREATE , VARIABLE ,
|
||
and user defined words which execute CREATE ;
|
||
|
||
2. dictionary space ALLOTted;
|
||
|
||
3. data in a valid mass storage block buffer.
|
||
See: "9.7 Multiprogramming Impact";
|
||
|
||
4. data area of user variables;
|
||
|
||
5. text input buffer and PAD up to the amount specified as the
|
||
minimum for each area.
|
||
|
||
A Standard Program may NOT address:
|
||
|
||
1. directly into the data or return stacks;
|
||
|
||
2. into a definition's name field, link field, or code field;
|
||
|
||
|
||
|
||
18
|
||
|
||
|
||
|
||
|
||
|
||
9. USAGE
|
||
|
||
|
||
3. into a definition's parameter field if not stored by the
|
||
application.
|
||
|
||
|
||
9.3 Return Stack
|
||
|
||
A Standard Program may cautiously use the return stack with the
|
||
following restrictions:
|
||
|
||
The return stack may not be accessed inside a do-loop for values
|
||
placed on the return stack before the loop was entered. Further,
|
||
neither I nor J may be used to obtain the index of a loop if
|
||
values are placed and remain on the return stack within the loop.
|
||
When the do-loop is executed all values placed on the return
|
||
stack within that loop must be removed before LOOP , +LOOP , or
|
||
LEAVE is executed. Similarly, all values placed on the return
|
||
stack within a colon definition must be removed before the colon
|
||
definition is terminated at ; or before EXIT is executed.
|
||
|
||
|
||
9.4 Compilation
|
||
|
||
The system uses the return stack and the dictionary in a system
|
||
dependent manner during the compilation of colon definitions.
|
||
Some words use the data stack in a system dependent manner during
|
||
compilation. See: "sys (11.7)"
|
||
|
||
|
||
9.5 Terminal Input and Output
|
||
|
||
|
||
9.5.1 KEY
|
||
|
||
A Standard System must receive all valid ASCII characters. Each
|
||
KEY receives one ASCII character, with more-significant bits
|
||
environmentally dependent and might be zero. KEY must receive as
|
||
many bits as are obtainable. A Standard Program without
|
||
environmental dependencies may only use the least significant 7-
|
||
bit ASCII character received by KEY . For example: KEY 127 AND
|
||
|
||
|
||
9.5.2 EXPECT
|
||
|
||
Control characters may be processed to allow system dependent
|
||
editing of the characters prior to receipt. Therefore, a
|
||
Standard Program may not anticipated that control characters can
|
||
be received.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
19
|
||
|
||
|
||
|
||
|
||
|
||
9. USAGE
|
||
|
||
|
||
9.5.3 EMIT
|
||
|
||
Because of the potential non-transportable action by terminal
|
||
devices of control characters, the use of ASCII control
|
||
characters is an environmental dependency. Each EMIT deals with
|
||
only one ASCII character. The ASCII character occupies the
|
||
least-significant 7 bits; the more-significant bits may be
|
||
environmentally dependent. Using the more-significant bits when
|
||
other than zero is an environmentally dependent usage. EMIT must
|
||
display as many bits as can be sent.
|
||
|
||
|
||
9.5.4 TYPE
|
||
|
||
Because of the potential non-transportable action by terminal
|
||
devices of control characters, the use of ASCII control
|
||
characters is an environmental dependency.
|
||
|
||
|
||
9.6 Transporting Programs Between Standard Systems
|
||
|
||
Further usage requirements are expected to be added for
|
||
transporting programs between Standard Systems.
|
||
|
||
|
||
9.7 Multiprogramming Impact
|
||
|
||
In a multiprogrammed system, Device Layer words and those words
|
||
which implicitly reference the Device Layer words may relinquish
|
||
control of the processor to other tasks. Although there is
|
||
insufficient experience to specify a standard for
|
||
multiprogramming, historical usage dictates that a programmer be
|
||
aware of the potential impact with regard to resources shared
|
||
between tasks. The only shared resources specified within the
|
||
Standard are block buffers. Therefore the address of a block
|
||
buffer returned by BLOCK or BUFFER becomes invalid during and
|
||
after the execution of any word marked by the attribute M in the
|
||
glossary or any words executing them. A block buffer is valid
|
||
only if its address is valid. See: "11.4 Attributes"
|
||
|
||
|
||
9.8 Numbers
|
||
|
||
Interpreted or compiled numbers are in the range
|
||
{-32,768..65,535}. See: "number conversion"
|
||
|
||
|
||
9.9 Control Structures
|
||
|
||
Control structures are compiled inside colon definitions.
|
||
Control structures can be nested but cannot overlap. For
|
||
additional limitations see DO .
|
||
|
||
|
||
|
||
|
||
|
||
20
|
||
|
||
|
||
|
||
|
||
|
||
10. ERROR CONDITIONS
|
||
|
||
|
||
|
||
|
||
10. ERROR CONDITIONS
|
||
|
||
|
||
|
||
10.1 Possible Actions on an Error
|
||
|
||
When an error condition occurs, a Standard System may take one or
|
||
more of the following actions:
|
||
|
||
1. ignore and continue;
|
||
|
||
2. display a message;
|
||
|
||
3. execute a particular word;
|
||
|
||
4. set interpret state and interpret a block;
|
||
|
||
5. set interpret state and begin interpretation;
|
||
|
||
6. other system dependent actions.
|
||
|
||
See: "7.1 Documentation Requirements"
|
||
|
||
|
||
10.2 General Error Conditions
|
||
|
||
The following error conditions apply in many situations. These
|
||
error conditions are listed below, but may occur at various times
|
||
and with various words.
|
||
|
||
1. input stream exhausted before encountering a required <name>
|
||
____
|
||
or delimiting character;
|
||
|
||
2. insufficient stack space or insufficient number of stack
|
||
entries during text interpretation or compilation;
|
||
|
||
3. a word not found and not a valid number, during text
|
||
interpretation or compilation;
|
||
|
||
4. compilation of incorrectly nested control structures;
|
||
|
||
5. execution of words restricted to compilation only, when not
|
||
in the compile state and while not compiling a colon
|
||
definition;
|
||
|
||
6. FORGETting within the system to a point that removes a word
|
||
required for correct execution;
|
||
|
||
7. insufficient space remaining in the dictionary;
|
||
|
||
8. a stack parameter out of range, e.g., a negative number when
|
||
a +n was specified in the glossary;
|
||
|
||
|
||
|
||
21
|
||
|
||
|
||
|
||
|
||
|
||
10. ERROR CONDITIONS
|
||
|
||
|
||
9. correct mass storage read or write was not possible.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
22
|
||
|
||
|
||
|
||
|
||
|
||
11. GLOSSARY NOTATION
|
||
|
||
|
||
|
||
|
||
11. GLOSSARY NOTATION
|
||
|
||
|
||
|
||
11.1 Order
|
||
|
||
The glossary definitions are listed in ASCII alphabetical order.
|
||
|
||
|
||
11.2 Capitalization
|
||
|
||
Word names are capitalized throughout this Standard.
|
||
|
||
|
||
11.3 Stack Notation
|
||
|
||
The stack parameters input to and output from a definition are
|
||
described using the notation:
|
||
|
||
before -- after
|
||
|
||
before stack parameters before execution
|
||
after stack parameters after execution
|
||
|
||
In this notation, the top of the stack is to the right. Words
|
||
may also be shown in context when appropriate.
|
||
|
||
Unless otherwise noted, all stack notation describes exectution
|
||
time. If it applies at compile time, the line is followed by:
|
||
(compiling) .
|
||
|
||
|
||
11.4 Attributes
|
||
|
||
Capitalized symbols indicate attributes of the defined words:
|
||
|
||
C The word may only be used during compilation of a colon
|
||
definition.
|
||
|
||
I Indicates that the word is IMMEDIATE and will execute during
|
||
compilation, unless special action is taken.
|
||
|
||
M This word has a potential multiprogramming impact.
|
||
See: "9.7 Multiprogramming Impact"
|
||
|
||
U A user variable.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
23
|
||
|
||
|
||
|
||
|
||
|
||
11. GLOSSARY NOTATION
|
||
|
||
|
||
11.5 Serial Numbers
|
||
|
||
When a substantive alteration to a word's definition is made or
|
||
when a new word is added, the serial number will be the last two
|
||
digits of the year of the Standard in which such change was made
|
||
(i.e., "83"). When such change is made within a Working Draft,
|
||
the number will be suffixed with the character identifying the
|
||
draft (i.e., "83A").
|
||
|
||
|
||
11.6 Pronunciation
|
||
|
||
The natural language pronunciation of word names is given in
|
||
double quotes (") where it differs from English pronunciation.
|
||
|
||
|
||
11.7 Stack Parameters
|
||
|
||
Unless otherwise stated, all references to numbers apply to 16-
|
||
bit signed integers. The implied range of values is shown as
|
||
{from..to}. The contents of an address is shown by double
|
||
braces, particularly for the contents of variables, i.e., BASE
|
||
{{2..72}}.
|
||
|
||
The following are the stack parameter abbreviations and types of
|
||
numbers used throughout the glossary. These abbreviations may be
|
||
suffixed with a digit to differentiate multiple parameters of the
|
||
same type.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
24
|
||
|
||
|
||
|
||
|
||
|
||
11. GLOSSARY NOTATION
|
||
|
||
|
||
Stack Number Range in Minimum
|
||
Abbrv. Type Decimal Field
|
||
|
||
flag boolean 0=false, else=true 16
|
||
true boolean -1 (as a result) 16
|
||
false boolean 0 0
|
||
b bit {0..1} 1
|
||
char character {0..127} 7
|
||
8b 8 arbitrary bits (byte) not applicable 8
|
||
16b 16 arbitrary bits not applicable 16
|
||
n number (weighted bits) {-32,768..32,767} 16
|
||
+n positive number {0..32,767} 16
|
||
u unsigned number {0..65,535} 16
|
||
w unspecified weighted number
|
||
(n or u) {-32,768..65,535} 16
|
||
addr address (same as u) {0..65,535} 16
|
||
32b 32 arbitrary bits not applicable 32
|
||
d double number {-2,147,483,648..
|
||
2,147,483,647} 32
|
||
+d positive double number {0..2,147,483,647} 32
|
||
ud unsigned double number {0..4,294,967,265} 32
|
||
wd unspecified weighted double
|
||
number (d or ud) {-2,147,483,648..
|
||
4,294,967,295} 32
|
||
sys 0, 1, or more system
|
||
dependent stack entries not applicable na
|
||
|
||
Any other symbol refers to an arbitrary signed 16-bit integer in
|
||
the range {-32,768..32,767}, unless otherwise noted.
|
||
|
||
Because of the use of two's complement arithmetic, the signed 16-
|
||
bit number (n) -1 has the same bit representation as the unsigned
|
||
number (u) 65,535. Both of these numbers are within the set of
|
||
unspecified weighted numbers (w). See: "arithmetic, two's
|
||
complement" "number" "number types" "stack, data"
|
||
|
||
|
||
11.8 Input Text
|
||
|
||
<name>
|
||
____
|
||
|
||
An arbitrary FORTH word accepted from the input stream.
|
||
This notation refers to text from the input stream, not to
|
||
values on the data stack. See: "10.2 General Error
|
||
Conditions"
|
||
|
||
ccc
|
||
___
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
25
|
||
|
||
|
||
|
||
|
||
|
||
11. GLOSSARY NOTATION
|
||
|
||
|
||
A sequence of arbitrary characters accepted from the input
|
||
stream until the first occurrence of the specified
|
||
delimiting character. The delimiter is accepted from the
|
||
input stream, but is not one of the characters ccc and is
|
||
___
|
||
therefore not otherwise processed. This notation refers to
|
||
text from the input stream, not to values on the data stack.
|
||
Unless noted otherwise, the number of characters accepted
|
||
may be from 0 to 255. See: "10.2 General Error Conditions"
|
||
|
||
|
||
11.9 References to other words and definitions
|
||
|
||
Glossary definitions may refer to other glossary definitions or
|
||
to definitions of terms. Such references are made using the
|
||
expression "See:". These references provide additional
|
||
information which apply as if the information is a portion of the
|
||
glossary entry using "See:".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
26
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
|
||
12.1 The Required Word Set Layers
|
||
|
||
The words of the Required Word Set are grouped to show like
|
||
characteristics. No implementation requirements should be
|
||
inferred from this grouping.
|
||
|
||
|
||
Nucleus layer
|
||
|
||
! * */ */MOD + +! - / /MOD 0< 0= 0> 1+ 1- 2+
|
||
2- 2/ < = > >R ?DUP @ ABS AND C! C@ CMOVE
|
||
CMOVE> COUNT D+ D< DEPTH DNEGATE DROP DUP EXECUTE
|
||
EXIT FILL I J MAX MIN MOD NEGATE NOT OR OVER PICK
|
||
R> R@ ROLL ROT SWAP U< UM* UM/MOD XOR
|
||
|
||
|
||
Device layer
|
||
|
||
BLOCK BUFFER CR EMIT EXPECT FLUSH KEY SAVE-BUFFERS
|
||
SPACE SPACES TYPE UPDATE
|
||
|
||
|
||
Interpreter layer
|
||
|
||
# #> #S #TIB ' ( -TRAILING . .( <# >BODY >IN
|
||
ABORT BASE BLK CONVERT DECIMAL DEFINITIONS FIND
|
||
FORGET FORTH FORTH-83 HERE HOLD LOAD PAD QUIT SIGN
|
||
SPAN TIB U. WORD
|
||
|
||
|
||
Compiler layer
|
||
|
||
+LOOP , ." : ; ABORT" ALLOT BEGIN COMPILE CONSTANT
|
||
CREATE DO DOES> ELSE IF IMMEDIATE LEAVE LITERAL LOOP
|
||
REPEAT STATE THEN UNTIL VARIABLE VOCABULARY WHILE [
|
||
['] [COMPILE] ]
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
27
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
|
||
|
||
|
||
12.2 The Required Word Set Glossary
|
||
|
||
! 16b addr -- 79 "store"
|
||
16b is stored at addr.
|
||
|
||
# +d1 -- +d2 79 "sharp"
|
||
The remainder of +d1 divided by the value of BASE is
|
||
converted to an ASCII character and appended to the output
|
||
string toward lower memory addresses. +d2 is the quotient
|
||
and is maintained for further processing. Typically used
|
||
between <# and #> .
|
||
|
||
#> 32b -- addr +n 79 "sharp-greater"
|
||
Pictured numeric output conversion is ended dropping 32b.
|
||
addr is the address of the resulting output string. +n is
|
||
the number of characters in the output string. addr and +n
|
||
together are suitable for TYPE .
|
||
|
||
#S +d -- 0 0 29 "sharp-s"
|
||
+d is converted appending each resultant character into the
|
||
pictured numeric output string until the quotient (see: # )
|
||
is zero. A single zero is added to the output string if the
|
||
number was initially zero. Typically used between <# and
|
||
#> .
|
||
|
||
#TIB -- addr U,83 "number-t-i-b"
|
||
The address of a variable containing the number of bytes in
|
||
the text input buffer. #TIB is accessed by WORD when BLK is
|
||
zero. {{0..capacity of TIB}} See: "input stream"
|
||
|
||
' -- addr M,83 "tick"
|
||
Used in the form:
|
||
' <name>
|
||
____
|
||
addr is the compilation address of <name>. An error
|
||
____
|
||
condition exists if <name> is not found in the currently
|
||
____
|
||
active search order.
|
||
|
||
( -- I,M,83 "paren"
|
||
-- (compiling)
|
||
Used in the form:
|
||
( ccc)
|
||
___
|
||
The characters ccc, delimited by ) (closing parenthesis),
|
||
___
|
||
are considered comments. Comments are not otherwise
|
||
processed. The blank following ( is not part of ccc. ( may
|
||
___
|
||
be freely used while interpreting or compiling. The number
|
||
of characters in ccc may be zero to the number of characters
|
||
___
|
||
remaining in the input stream up to the closing parenthesis.
|
||
|
||
* w1 w2 -- w3 79 "times"
|
||
w3 is the least-significant 16 bits of the arithmetic
|
||
product of w1 times w2.
|
||
|
||
|
||
|
||
28
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
*/ n1 n2 n3 -- n4 83 "times-divide"
|
||
n1 is first multiplied by n2 producing an intermediate 32-
|
||
bit result. n4 is the floor of the quotient of the
|
||
intermediate 32-bit result divided by the divisor n3. The
|
||
product of n1 times n2 is maintained as an intermediate 32-
|
||
bit result for greater precision than the otherwise
|
||
equivalent sequence: n1 n2 * n3 / . An error condition
|
||
results if the divisor is zero or if the quotient falls
|
||
outside of the range {-32,768..32,767}. See: "division,
|
||
floored"
|
||
|
||
*/MOD n1 n2 n3 -- n4 n5 83 "times-divide-mod"
|
||
n1 is first multiplied by n2 producing an intermediate 32-
|
||
bit result. n4 is the remainder and n5 is the floor of the
|
||
quotient of the intermediate 32-bit result divided by the
|
||
divisor n3. A 32-bit intermediate product is used as for
|
||
*/ . n4 has the same sign as n3 or is zero. An error
|
||
condition results if the divisor is zero or if the quotient
|
||
falls outside of the range {-32,768..32,767}. See:
|
||
"division, floored"
|
||
|
||
+ w1 w2 -- w3 79 "plus"
|
||
w3 is the arithmetic sum of w1 plus w2.
|
||
|
||
+! w1 addr -- 79 "plus-store"
|
||
w1 is added to the w value at addr using the convention for
|
||
+ . This sum replaces the original value at addr.
|
||
|
||
+LOOP n -- C,I,83 "plus-loop"
|
||
sys -- (compiling)
|
||
n is added to the loop index. If the new index was
|
||
incremented across the boundary between limit-1 and limit
|
||
then the loop is terminated and loop control parameters are
|
||
discarded. When the loop is not terminated, execution
|
||
continues to just after the corresponding DO . sys is
|
||
balanced with its corresponding DO . See: DO
|
||
|
||
, 16b -- 79 "comma"
|
||
ALLOT space for 16b then store 16b at HERE 2- .
|
||
|
||
- w1 w2 -- w3 79 "minus"
|
||
w3 is the result of subtracting w2 from w1.
|
||
|
||
-TRAILING addr +n1 -- addr +n2 79 "dash-trailing"
|
||
The character count +n1 of a text string beginning at addr
|
||
is adjusted to exclude trailing spaces. If +n1 is zero,
|
||
then +n2 is also zero. If the entire string consists of
|
||
spaces, then +n2 is zero.
|
||
|
||
. n -- M,79 "dot"
|
||
The absolute value of n is displayed in a free field format
|
||
with a leading minus sign if n is negative.
|
||
|
||
|
||
|
||
|
||
|
||
29
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
." -- C,I,83 "dot-quote"
|
||
-- (compiling)
|
||
Used in the form:
|
||
." ccc"
|
||
___
|
||
Later execution will display the characters ccc up to but
|
||
___
|
||
not including the delimiting " (close-quote). The blank
|
||
following ." is not part of ccc.
|
||
___
|
||
|
||
.( -- I,M,83 "dos-paren"
|
||
-- (compiling)
|
||
Used in the form:
|
||
.( ccc)
|
||
___
|
||
The characters ccc up to but not including the delimiting )
|
||
___
|
||
(closing parenthesis) are displayed. The blank following .(
|
||
is not part of ccc.
|
||
___
|
||
|
||
/ n1 n2 -- n3 83 "divide"
|
||
n3 is the floor of the quotient of n1 divided by the divisor
|
||
n2. An error condition results if the divisor is zero or if
|
||
the quotient falls outside of the range {-32,768..32,767}.
|
||
See: "division, floored"
|
||
|
||
/MOD n1 n2 -- n3 n4 83 "divide-mod"
|
||
n3 is the remainder and n4 the floor of the quotient of n1
|
||
divided by the divisor n2. n3 has the same sign as n2 or is
|
||
zero. An error condition results if the divisor is zero or
|
||
if the quotient falls outside of the range
|
||
{-32,768..32,767}. See: "division, floored"
|
||
|
||
0< n -- flag 83 "zero-less"
|
||
flag is true if n is less than zero (negative).
|
||
|
||
0= w -- flag 83 "zero-equals"
|
||
flag is true if w is zero.
|
||
|
||
0> n -- flag 83 "zero-greater"
|
||
flag is true if n is greater than zero.
|
||
|
||
1+ w1 -- w2 79 "one-plus"
|
||
w2 is the result of adding one to w1 according to the
|
||
operations of + .
|
||
|
||
1- w1 -- w2 79 "one-minus"
|
||
w2 is the result of subtracting one from w1 according to the
|
||
operation of - .
|
||
|
||
2+ w1 -- w2 79 "two-plus"
|
||
w2 is the result of adding two to w1 according to the
|
||
operation of + .
|
||
|
||
2- w1 -- w2 79 "two-minus"
|
||
w2 is the result of subtracting two from w1 according to the
|
||
operation of - .
|
||
|
||
|
||
|
||
|
||
30
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
2/ n1 -- n2 83 "two-divide"
|
||
n2 is the result of arithmetically shifting n1 right one
|
||
bit. The sign is included in the shift and remains
|
||
unchanged.
|
||
|
||
: -- sys M,79 "colon"
|
||
A defining word executed in the form:
|
||
: <name> ... ;
|
||
____
|
||
Create a word definition for <name> in the compilation
|
||
____
|
||
vocabulary and set compilation state. The search order is
|
||
changed so that the first vocabulary in the search order is
|
||
changed so that the first vocabulary in the search order is
|
||
replaced by the compilation vocabulary. The compilation
|
||
vocabulary is unchanged. The text from the input stream is
|
||
subsequently compiled. <name> is called a "colon
|
||
____
|
||
definition". The newly created word definition for <name>
|
||
____
|
||
cannot be found in the dictionary until the corresponding ;
|
||
or ;CODE is successfully processed.
|
||
|
||
An error condition exists if a word is not found and cannot
|
||
be converted to a number or if, during compilation from mass
|
||
storage, the input stream is exhausted before encountering ;
|
||
or ;CODE . sys is balanced with its corresponding ; . See:
|
||
"compilation" "9.4 Compilation"
|
||
|
||
; -- C,I,79 "semi-colon"
|
||
sys -- (compiling)
|
||
Stops compilation of a colon definition, allows the <name>
|
||
____
|
||
of this colon definition to be found in the dictionary, sets
|
||
interpret state and compiles EXIT (or a system dependent
|
||
word which performs an equivalent function). sys is
|
||
balanced with its corresponding : . See: EXIT : "stack,
|
||
return" "9.4 Compilation"
|
||
|
||
< n1 n2 -- flag 83 "less-than"
|
||
flag is true if n1 is less than n2.
|
||
-32678 32767 < must return true.
|
||
-32768 0 < must return true.
|
||
|
||
<# -- 79 "less-sharp"
|
||
Initialize pictured numeric output conversion. The words:
|
||
# #> #S <# HOLD SIGN
|
||
can be used to specify the conversion of a double number
|
||
into an ASCII text string stored in right-to-left order.
|
||
|
||
= w1 w2 -- flag 83 "equals"
|
||
flag is true if w1 is equal to w2.
|
||
|
||
> n1 n2 -- flag 83 "greater-than"
|
||
flag is true if n1 is greater than n2.
|
||
-32768 32767 > must return false.
|
||
-32768 0 > must return false.
|
||
|
||
|
||
|
||
|
||
|
||
31
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
>BODY addr1 -- addr2 83 "to-body"
|
||
addr2 is the parameter field address corresponding to the
|
||
compilation address addr1. See: "9.2 Addressable Memory"
|
||
|
||
>IN -- addr U,79 "to-in"
|
||
The address of a variable which contains the present
|
||
character offset within the input stream {{0..the number of
|
||
characters in the input stream}}. See: WORD
|
||
|
||
>R 16b -- C,79 "to-r"
|
||
Transfers 16b to the return stack. See "9.3 Return Stack"
|
||
|
||
?DUP 16b -- 16b 16b 79 "question-dupe"
|
||
or 0 -- 0
|
||
Duplicate 16b if it is non-zero.
|
||
|
||
@ addr -- 16b 79 "fetch"
|
||
16b is the value at addr.
|
||
|
||
ABORT 79
|
||
Clears the data stack and performs the function of QUIT .
|
||
No message is displayed.
|
||
|
||
ABORT" flag -- C,I,83 "abort-quote"
|
||
-- (compiling)
|
||
Used in the form:
|
||
flag ABORT" ccc"
|
||
___
|
||
When later executed, if flag is true the characters ccc,
|
||
___
|
||
delimited by " (close-quote), are displayed and then a
|
||
system dependent error abort sequence, including the
|
||
function of ABORT , is performed. If flag is false, the
|
||
flag is dropped and execution continues. The blank
|
||
following ABORT" is not part of ccc.
|
||
___
|
||
|
||
ABS n -- u 79 "absolute"
|
||
u is the absolute value of n. If n is -32,768 then u is the
|
||
same value. See: "arithmetic, two's complement"
|
||
|
||
ALLOT w -- 79
|
||
Allocates w bytes in the dictionary. The address of the
|
||
next available dictionary entry is updated accordingly.
|
||
|
||
AND 16b1 16b2 -- 16b3 79
|
||
16b3 is the bit-by-bit logical 'and' of 16b1 with 16b2.
|
||
|
||
BASE -- addr U,83
|
||
The address of a variable containing the current numeric
|
||
conversion radix. {{2..72}}
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
32
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
BEGIN -- C,I,79
|
||
-- sys (compiling)
|
||
Used in the form:
|
||
BEGIN ... flag UNTIL
|
||
or
|
||
BEGIN ... flag WHILE ... REPEAT
|
||
BEGIN marks the start of a word sequence for repetitive
|
||
execution. A BEGIN-UNTIL loop will be repeated until flag
|
||
is true. A BEGIN-WHILE-REPEAT will be repeated until flag
|
||
is false. The words after UNTIL or REPEAT will be executed
|
||
when either loop is finished. sys is balanced with its
|
||
corresponding UNTIL or WHILE . See: "9.9 Control
|
||
Structures"
|
||
|
||
BLK -- addr U,79 "b-l-k"
|
||
The address of a variable containing the number of the mass
|
||
storage block being interpreted as the input stream. If the
|
||
value of BLK is zero the input stream is taken from the text
|
||
input buffer. {{0..the number of blocks available -1}}
|
||
See: TIB "input stream"
|
||
|
||
BLOCK u -- addr M,83
|
||
addr is the address of the assigned buffer of the first byte
|
||
of block u. If the block occupying that buffer is not block
|
||
u and has been UPDATEed it is transferred to mass storage
|
||
before assigning the buffer. If block u is not already in
|
||
memory, it is transferred from mass storage into an assigned
|
||
block buffer. A block may not be assigned to more than one
|
||
buffer. If u is not an available block number, an error
|
||
condition exists. Only data within the last buffer
|
||
referenced by BLOCK or BUFFER is valid. The contents of a
|
||
block buffer must not be changed unless the change may be
|
||
transferred to mass storage.
|
||
|
||
BUFFER u -- addr M,83
|
||
Assigns a block buffer to block u. addr is the address of
|
||
the first byte of the block within its buffer. This
|
||
function is fully specified by the definition for BLOCK
|
||
except that if the block is not already in memory it might
|
||
not be transferred from mass storage. The contents of the
|
||
block buffer assigned to block u by BUFFER are unspecified.
|
||
|
||
C! 16b addr -- 79 "c-store"
|
||
The least-significant 8 bits of 16b are stored into the byte
|
||
at addr.
|
||
|
||
C@ addr -- 8b 79 "c-fetch"
|
||
8b is the contents of the byte at addr.
|
||
|
||
CMOVE addr1 addr2 u -- 83 "c-move"
|
||
Move u bytes beginning at address addr1 to addr2. The byte
|
||
at addr1 is moved first, proceeding toward high memory. If
|
||
u is zero nothing is moved.
|
||
|
||
|
||
|
||
|
||
33
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
CMOVE> addr1 addr2 u -- 83 "c-move-up"
|
||
Move the u bytes at address addr1 to addr2. The move begins
|
||
by moving the byte at (addr1 plus u minus 1) to (addr2 plus
|
||
u minus 1) and proceeds to successively lower addresses for
|
||
u bytes. If u is zero nothing is moved. (Useful for
|
||
sliding a string towards higher addresses).
|
||
|
||
COMPILE -- C,83
|
||
Typically used in the form:
|
||
: <name> ... COMPILE <namex> ... ;
|
||
When <name> is executed, the compilation address compiled
|
||
for <namex> is compiled and not executed. <name> is
|
||
typically immediate and <namex> is typically not immediate.
|
||
See: "compilation"
|
||
|
||
CONSTANT 16b -- M,83
|
||
A defining word executed in the form:
|
||
16b CONSTANT <name>
|
||
____
|
||
Creates a dictionary entry for <name> so that when <name> is
|
||
____ ____
|
||
later executed, 16b will be left on the stack.
|
||
|
||
CONVERT +d1 addr1 -- +d2 addr2 79
|
||
+d2 is the result of converting the characters within the
|
||
text beginning at addr1+2 into digits, using the value of
|
||
BASE , and accumulating each into +d1 after multiplying +d1
|
||
by the value of BASE . Conversion continues until an
|
||
unconvertible character is encounter. addr2 is the location
|
||
of the first unconvertible character.
|
||
|
||
COUNT addr1 -- addr2 +n 79
|
||
addr2 is addr1+1 and +n is the length of the counted string
|
||
at addr1. The byte at addr1 contains the byte count +n.
|
||
Range of +n is {0.255} See: "string, counted"
|
||
|
||
CR -- M,79 "c-r"
|
||
Displays a carriage-return and line-feed or equivalent
|
||
operation.
|
||
|
||
CREATE -- M,79
|
||
A defining word executed in the form:
|
||
CREATE <name>
|
||
____
|
||
Creates a dictionary entry for <name>. After <name> is
|
||
____ ____
|
||
created, the next available dictionary location is the first
|
||
byte of <name>'s parameter field. When <name> is
|
||
____ ____
|
||
subsequently executed, the address of the first byte of
|
||
<name>'s parameter field is left on the stack. CREATE does
|
||
____
|
||
not allocate space in <name>'s parameter field.
|
||
____
|
||
|
||
D+ wd1 wd2 -- wd3 79 "d-plus"
|
||
wd3 is the arithmetic sum of wd1 plus wd2.
|
||
|
||
D< d1 d2 -- flag 83 "d-less-than"
|
||
flag is true if d1 is less than d2 according to the
|
||
operation of < except extended to 32 bits.
|
||
|
||
|
||
|
||
34
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
DECIMAL -- 79
|
||
Set the input-output numeric conversion base to ten.
|
||
|
||
DEFINITIONS -- 79
|
||
The compilation vocabulary is changed to be the same as the
|
||
first vocabulary in the search order. See: "vocabulary,
|
||
compilation"
|
||
|
||
DEPTH -- +n 79
|
||
+n is the number of 16-bit values contained in the data
|
||
stack before +n was placed on the stack.
|
||
|
||
DNEGATE d1 -- d2 79 "d-negate"
|
||
d2 is the two's complement of d1.
|
||
|
||
DO w1 w2 -- C,I,83
|
||
-- sys (compiling)
|
||
Used in the form:
|
||
DO ... LOOP
|
||
or
|
||
DO ... +LOOP
|
||
Begins a loop which terminates based on control parameters.
|
||
The loop index begins at w2, and terminates based on the
|
||
limit w1. See LOOP and +LOOP for details on how the loop is
|
||
terminated. The loop is always executed at least once. For
|
||
example: w DUP DO ... LOOP executes 65,536 times. sys is
|
||
balanced with its corresponding LOOP or +LOOP . See: "9.9
|
||
Control Structures"
|
||
|
||
An error condition exists if insufficient space is available
|
||
for at least three nesting levels.
|
||
|
||
DOES> -- addr C,I,83 "does"
|
||
-- (compiling)
|
||
Defines the execution-time action of a word created by a
|
||
high-level defining word. Used in the form:
|
||
: <namex> ... <create> ... DOES> ... ;
|
||
and then
|
||
<namex> <name>
|
||
____
|
||
where <create> is CREATE or any user defined word which
|
||
executes CREATE .
|
||
|
||
Marks the termination of the defining part of the defining
|
||
word <namex> and then begins the definition of the
|
||
execution-time action for words that will later be defined
|
||
by <namex>. When <name> is later executed, the address of
|
||
____
|
||
<name>'s parameter field is placed on the stack and then the
|
||
____
|
||
sequence of words between DOES> and ; are executed.
|
||
|
||
DROP 16b -- 79
|
||
16b is removed from the stack.
|
||
|
||
DUP 16b -- 16b 16b 79 "dupe"
|
||
Duplicate 16b.
|
||
|
||
|
||
|
||
35
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
ELSE -- C,I,79
|
||
sys1 -- sys2 (compiling)
|
||
Used in the form:
|
||
flag IF ... ELSE ... THEN
|
||
ELSE executes after the true part following IF . ELSE
|
||
forces execution to continue at just after THEN . sys1 is
|
||
balanced with its corresponding IF . sys2 is balanced with
|
||
its corresponding THEN . See: IF THEN
|
||
|
||
EMIT 16b -- M,83
|
||
The least-significant 7-bit ASCII character is displayed.
|
||
SEE: "9.5.3 EMIT"
|
||
|
||
EXECUTE addr -- 79
|
||
The word definition indicated by addr is executed. An error
|
||
condition exists if addr is not a compilation address
|
||
|
||
EXIT -- C,79
|
||
Compiled within a colon definition such that when executed,
|
||
that colon definition returns control to the definition that
|
||
passed control to it by returning control to the return
|
||
point on the top of the return stack. An error condition
|
||
exists if the top of the return stack does not contain a
|
||
valid return point. May not be used within a do-loop. See:
|
||
; "stack, return" "9.3 Return Stack"
|
||
|
||
EXPECT addr +n -- M,83
|
||
Receive characters and store each into memory. The transfer
|
||
begins at addr proceeding towards higher addresses one byte
|
||
per character until either a "return" is received or until
|
||
+n characters have been transferred. No more than +n
|
||
characters will be stored. The "return" is not stored into
|
||
memory. No characters are received or transferred if +n is
|
||
zero. All characters actually received and stored into
|
||
memory will be displayed, with the "return" displaying as a
|
||
space. See: SPAN "9.5.2 EXPECT"
|
||
|
||
FILL addr u 8b -- 83
|
||
u bytes of memory beginning at addr are set to 8b. No
|
||
action is taken if u is zero.
|
||
|
||
FIND addr1 -- addr2 n 83
|
||
addr1 is the address of a counted string. The string
|
||
contains a word name to be located in the currently active
|
||
search order. If the word is not found, addr2 is the string
|
||
address addr1, and n is zero. If the word is found, addr2
|
||
is the compilation address and n is set to one of two non-
|
||
zero values. If the word found has the immediate attribute,
|
||
n is set to one. If the word is non-immediate, n is set to
|
||
minus one (true).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
36
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
FLUSH -- M,83
|
||
Performs the function of SAVE-BUFFERS then unassigns all
|
||
block buffers. (This may be useful for mounting or changing
|
||
mass storage media).
|
||
|
||
FORGET -- M,83
|
||
Used in the form:
|
||
FORGET <name>
|
||
____
|
||
If <name> is found in the compilation vocabulary, delete
|
||
____
|
||
<name> from the dictionary and all words added to the
|
||
____
|
||
dictionary after <name> regardless of their vocabulary.
|
||
____
|
||
Failure to find <name> is an error condition. An error
|
||
____
|
||
condition also exists if the compilation vocabulary is
|
||
deleted. See: "10.2 General Error Conditions"
|
||
|
||
FORTH -- 83
|
||
The name of the primary vocabulary. Execution replaces the
|
||
first vocabulary in the search order with FORTH . FORTH is
|
||
initially the compilation vocabulary and the first
|
||
vocabulary in the search order. New definitions become part
|
||
of the FORTH vocabulary until a different compilation
|
||
vocabulary is established. See: VOCABULARY
|
||
|
||
FORTH-83 -- 83
|
||
Assures that a FORTH-83 Standard System is available,
|
||
otherwise an error condition exists.
|
||
|
||
HERE -- addr 79
|
||
The address of the next available dictionary location.
|
||
|
||
HOLD char -- 79
|
||
char is inserted into a pictured numeric output string.
|
||
Typically used between <# and #>.
|
||
|
||
I -- w C,79
|
||
w is a copy of the loop index. May only be used in the
|
||
form:
|
||
DO ... I ... LOOP
|
||
or
|
||
DO ... I ... +LOOP
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
37
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
IF flag -- C,I,79
|
||
-- sys (compiling)
|
||
Used in the form:
|
||
flag IF ... ELSE ... THEN
|
||
or
|
||
flag IF ... THEN
|
||
If flag is true, the words following IF are executed and the
|
||
words following ELSE until just after THEN are skipped. The
|
||
ELSE part is optional.
|
||
|
||
If flag is false, the words from IF through ELSE , or from
|
||
IF through THEN (when no ELSE is used), are skipped. sys is
|
||
balanced with its corresponding ELSE or THEN . See: "9.9
|
||
Control Structures"
|
||
|
||
IMMEDIATE -- 79
|
||
Marks the most recently created dictionary entry as a word
|
||
which will be executed when encountered during compilation
|
||
rather than compiled.
|
||
|
||
J -- w C,79
|
||
w is a copy of the index of the next outer loop. May only
|
||
be used within a nested DO-LOOP or DO-+LOOP in the form, for
|
||
example:
|
||
DO ... DO ... J ... LOOP ... +LOOP
|
||
|
||
KEY -- 16b M,83
|
||
The least-significant 7 bits of 16b is the next ASCII
|
||
character received. All valid ASCII characters can be
|
||
received. Control characters are not processed by the
|
||
system for any editing purpose. Characters received by KEY
|
||
will not be displayed. See: "9.5.1 KEY"
|
||
|
||
LEAVE -- C,I,83
|
||
-- (compiling)
|
||
Transfers execution to just beyond the next LOOP or +LOOP .
|
||
The loop is terminated and loop control parameters are
|
||
discarded. May only be used in the form:
|
||
DO ... LEAVE ... LOOP
|
||
or
|
||
DO ... LEAVE ... +LOOP
|
||
LEAVE may appear within other control structures which are
|
||
nested within the do-loop structure. More than one LEAVE
|
||
may appear within a do-loop. See: "9.3 Return Stack"
|
||
|
||
LITERAL -- 16b C,I,79
|
||
16b -- (compiling)
|
||
Typically used in the form:
|
||
[ 16b ] LITERAL
|
||
Compiles a system dependent operation so that when later
|
||
executed, 16b will be left on the stack.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
38
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
LOAD u -- M,79
|
||
The contents of >IN and BLK , which locate the current input
|
||
stream, are saved. The input stream is then redirected to
|
||
the beginning of screen u by setting >IN to zero and BLK to
|
||
u. The screen is then interpreted. If interpretation from
|
||
screen u is not terminated explicitly it will be terminated
|
||
when the input stream is exhausted and then the contents of
|
||
>IN and BLK will be restored. An error condition exists if
|
||
u is zero. See: >IN BLK BLOCK
|
||
|
||
LOOP -- C,I,83
|
||
sys -- (compiling)
|
||
Increments the DO-LOOP index by one. If the new index was
|
||
incremented across the boundary between limit-1 and limit
|
||
the loop is terminated and loop control parameters are
|
||
discarded. When the loop is not terminated, execution
|
||
continues to just after the corresponding DO . sys is
|
||
balanced with its corresponding DO . See: DO
|
||
|
||
MAX n1 n2 -- n3 79 "max"
|
||
n3 is the greater of n1 and n2 according to the operation of
|
||
> .
|
||
|
||
MIN n1 n2 -- n3 79 "min"
|
||
n3 is the lesser of n1 and n2 according to the operation of
|
||
< .
|
||
|
||
MOD n1 n2 -- n3 83
|
||
n3 is the remainder after dividing n1 by the divisor n2. n3
|
||
has the same sign as n2 or is zero. An error condition
|
||
results if the divisor is zero or if the quotient falls
|
||
outside of the range {-32,768..32,767}. See: "division,
|
||
floored"
|
||
|
||
NEGATE n1 -- n2 79
|
||
n2 is the two's complement of n1, i.e, the difference of
|
||
zero less n1.
|
||
|
||
NOT 16b1 -- 16b2 83
|
||
16b2 is the one's complement of 16b1.
|
||
|
||
OR 16b1 16b2 -- 16b3 79
|
||
16b3 is the bit-by-bit inclusive-or of 16b1 with 16b2.
|
||
|
||
OVER 16b1 16b2 -- 16b1 16b2 16b3 79
|
||
16b3 is a copy of 16b1.
|
||
|
||
PAD -- addr 83
|
||
The lower address of a scratch area used to hold data for
|
||
intermediate processing. The address or contents of PAD may
|
||
change and the data lost if the address of the next
|
||
available dictionary location is changed. The minimum
|
||
capacity of PAD is 84 characters.
|
||
|
||
|
||
|
||
|
||
39
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
PICK +n -- 16b 83
|
||
16b is a copy of the +nth stack value, not counting +n
|
||
itself. {0..the number of elements on stack-1}
|
||
0 PICK is equivalent to DUP
|
||
1 PICK is equivalent to OVER
|
||
|
||
QUIT -- 79
|
||
Clears the return stack, sets interpret state, accepts new
|
||
input from the current input device, and begins text
|
||
interpretation. No message is displayed.
|
||
|
||
R> -- 16b C,79 "r-from"
|
||
16b is removed from the return stack and transferred to the
|
||
data stack. See: "9.3 Return Stack"
|
||
|
||
R@ -- 16b C,79 "r-fetch"
|
||
16b is a copy of the top of the return stack.
|
||
|
||
REPEAT -- C,I,79
|
||
sys -- (compiling)
|
||
Used in the form:
|
||
BEGIN ... flag WHILE ... REPEAT
|
||
At execution time, REPEAT continues execution to just after
|
||
the corresponding BEGIN . sys is balanced with its
|
||
corresponding WHILE . See: BEGIN
|
||
|
||
ROLL +n -- 83
|
||
The +nth stack value, not counting +n itself is first
|
||
removed and then transferred to the top of the stack, moving
|
||
the remaining values into the vacated position. {0..the
|
||
number of elements on the stack-1}
|
||
2 ROLL is equivalent to ROT
|
||
0 ROLL is a null operation
|
||
|
||
ROT 16b1 16b2 16b3 -- 16b2 16b3 16b1 79 "rote"
|
||
The top three stack entries are rotated, bringing the
|
||
deepest to the top.
|
||
|
||
SAVE-BUFFERS -- M,79 "save-buffers"
|
||
The contents of all block buffers marked as UPDATEed are
|
||
written to their corresponding mass storage blocks. All
|
||
buffers are marked as no longer being modified, but may
|
||
remain assigned.
|
||
|
||
SIGN n -- 83
|
||
If n is negative, an ASCII "-" (minus sign) is appended to
|
||
the pictured numeric output string. Typically used between
|
||
<# and #> .
|
||
|
||
SPACE -- M,79
|
||
Displays an ASCII space.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
40
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
SPACES +n -- M,79
|
||
Displays +n ASCII spaces. Nothing is displayed if +n is
|
||
zero.
|
||
|
||
SPAN -- addr U,83
|
||
The address of a variable containing the count of characters
|
||
actually received and stored by the last execution of
|
||
EXPECT . See: EXPECT
|
||
|
||
STATE -- addr U,79
|
||
The address of a variable containing the compilation state.
|
||
A non-zero content indicates compilation is occurring, but
|
||
the value itself is system dependent. A Standard Program
|
||
may not modify this variable.
|
||
|
||
SWAP 16b1 16b2 -- 16b2 16b1 79
|
||
The top two stack entries are exchanged.
|
||
|
||
THEN -- C,I,79
|
||
sys -- (compiling)
|
||
Used in the form:
|
||
flag IF ... ELSE ... THEN
|
||
or
|
||
flag IF ... THEN
|
||
THEN is the point where execution continues after ELSE , or
|
||
IF when no ELSE is present. sys is balanced with its
|
||
corresponding IF or ELSE . See: IF ELSE
|
||
|
||
TIB -- addr 83 "t-i-b"
|
||
The address of the text input buffer. This buffer is used
|
||
to hold characters when the input stream is coming from the
|
||
current input device. The minimum capacity of TIB is 80
|
||
characters.
|
||
|
||
TYPE addr +n -- M,79
|
||
+n characters are displayed from memory beginning with the
|
||
character at addr and continuing through consecutive
|
||
addresses. Nothing is displayed if +n is zero. See:
|
||
"9.5.4 TYPE"
|
||
|
||
U. u -- M,79 "u-dot"
|
||
u is displayed as an unsigned number in a free-field format.
|
||
|
||
U< u1 u2 -- flag 83 "u-less-than"
|
||
flag is true if u1 is less than u2.
|
||
|
||
UM* u1 u2 -- ud 83 "u-m-times"
|
||
ud is the unsigned product of u1 times u2. All values and
|
||
arithmetic are unsigned.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
41
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
UM/MOD ud u1 -- u2 u3 83 "u-m-divide-mod"
|
||
u2 is the remainder and u3 is the floor of the quotient
|
||
after dividing ud by the divisor u1. All values and
|
||
arithmetic are unsigned. An error condition results if the
|
||
divisor is zero or if the quotient lies outside the range
|
||
{0..65,535}. See: "floor, arithmetic"
|
||
|
||
UNTIL flag -- C,I,79
|
||
sys -- (compiling)
|
||
Used in the form:
|
||
BEGIN ... flag UNTIL
|
||
Marks the end of a BEGIN-UNTIL loop which will terminate
|
||
based on flag. If flag is true, the loop is terminated. If
|
||
flag is false, execution continues to just after the
|
||
corresponding BEGIN . sys is balanced with its
|
||
corresponding BEGIN . See: BEGIN
|
||
|
||
UPDATE -- 79
|
||
The currently valid block buffer is marked as modified.
|
||
Blocks marked as modified will subsequently be automatically
|
||
transferred to mass storage should its memory buffer be
|
||
needed for storage of a different block or upon execution of
|
||
FLUSH or SAVE-BUFFERS .
|
||
|
||
VARIABLE -- M,79
|
||
A defining word executed in the form:
|
||
VARIABLE <name>
|
||
____
|
||
A dictionary entry for <name> is created and two bytes are
|
||
____
|
||
ALLOTted in its parameter field. This parameter field is to
|
||
be used for contents of the variable. The application is
|
||
responsible for initializing the contents of the variable
|
||
which it creates. When <name> is later executed, the
|
||
____
|
||
address of its parameter field is placed on the stack.
|
||
|
||
VOCABULARY -- M,83
|
||
A defining word executed in the form:
|
||
VOCABULARY <name>
|
||
____
|
||
A dictionary entry for <name> is created which specifies a
|
||
____
|
||
new ordered list of word definitions. Subsequent execution
|
||
of <name> replaces the first vocabulary in the search order
|
||
____
|
||
with <name>. When <name> becomes the compilation vocabulary
|
||
____ ____
|
||
new definitions will be appended to <name>'s list. See:
|
||
____
|
||
DEFINITIONS "search order"
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
42
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
WHILE flag -- C,I,79
|
||
sys1 -- sys2 (compiling)
|
||
Used in the form:
|
||
BEGIN ... flag WHILE ... REPEAT
|
||
Selects conditional execution based on flag. When flag is
|
||
true, execution continues to just after the WHILE through to
|
||
the REPEAT which then continues execution back to just after
|
||
the BEGIN . When flag is false, execution continues to just
|
||
after the REPEAT , exiting the control structure. sys1 is
|
||
balanced with its corresponding BEGIN . sys2 is balanced
|
||
with its corresponding REPEAT . See: BEGIN
|
||
|
||
WORD char -- addr M,83
|
||
Generates a counted string by non-destructively accepting
|
||
characters from the input stream until the delimiting
|
||
character char is encountered or the input stream is
|
||
exhausted. Leading delimiters are ignored. The entire
|
||
character string is stored in memory beginning at addr as a
|
||
sequence of bytes. The string is followed by a blank which
|
||
is not included in the count. The first byte of the string
|
||
is the number of characters {0..255}. If the string is
|
||
longer than 255 characters, the count is unspecified. If
|
||
the input stream is already exhausted as WORD is called,
|
||
then a zero length character string will result.
|
||
|
||
If the delimiter is not found the value of >IN is the size
|
||
of the input stream. If the delimiter is found >IN is
|
||
adjusted to indicate the offset to the character following
|
||
the delimiter. #TIB is unmodified.
|
||
|
||
The counted string returned by WORD may reside in the "free"
|
||
dictionary area at HERE or above. Note that the text
|
||
interpreter may also use this area. See: "input stream"
|
||
|
||
XOR 16b1 16b2 -- 16b3 79 "x-or"
|
||
16b3 is the bit-by-bit exclusive-or of 16b1 with 16b2.
|
||
|
||
[ -- I,79 "left-bracket"
|
||
-- (compiling)
|
||
Sets interpret state. The text from the input stream is
|
||
subsequently interpreted. For typical usage see LITERAL .
|
||
See: ]
|
||
|
||
['] -- addr C,I,M,83 "bracket-
|
||
-- (compiling) tick"
|
||
Used in the form:
|
||
['] <name>
|
||
____
|
||
Compiles the compilation address addr of <name> as a
|
||
____
|
||
literal. When the colon definition is later executed addr
|
||
is left on the stack. An error condition exists if <name>
|
||
____
|
||
is not found in the currently active search order. See:
|
||
LITERAL
|
||
|
||
|
||
|
||
|
||
|
||
43
|
||
|
||
|
||
|
||
|
||
|
||
12. REQUIRED WORD SET
|
||
|
||
|
||
[COMPILE] -- C,I,M,79 "bracket-
|
||
-- (compiling) compile"
|
||
Used in the form:
|
||
[COMPILE] <name>
|
||
____
|
||
Forces compilation of the following word <name>. This
|
||
____
|
||
allows compilation of an immediate word when it would
|
||
otherwise have been executed.
|
||
|
||
] -- 79 "right-bracket"
|
||
Sets compilation state. The text from the input stream is
|
||
subsequently compiled. For typical usage see LITERAL .
|
||
See: [
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
44
|
||
|
||
|
||
|
||
|
||
|
||
13. DOUBLE NUMBER EXTENSION WORD SET
|
||
|
||
|
||
|
||
|
||
13. DOUBLE NUMBER EXTENSION WORD SET
|
||
|
||
|
||
|
||
13.1 The Double Number Extension Word Set Layers
|
||
|
||
|
||
Nucleus layer
|
||
|
||
2! 2@ 2DROP 2DUP 2OVER 2ROT 2SWAP D+ D- D0= D2/
|
||
D< D= DABS DMAX DMIN DNEGATE DU<
|
||
|
||
|
||
Device layer
|
||
|
||
none
|
||
|
||
|
||
Interpreter layer
|
||
|
||
D. D.R
|
||
|
||
|
||
Compiler layer
|
||
|
||
2CONSTANT 2VARIABLE
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
45
|
||
|
||
|
||
|
||
|
||
|
||
13. DOUBLE NUMBER EXTENSION WORD SET
|
||
|
||
|
||
|
||
|
||
|
||
13.2 The Double Number Extension Word Set Glossary
|
||
|
||
2! 32b addr -- 79 "two-store"
|
||
32b is stored at addr. See: "number"
|
||
|
||
2@ addr -- 32b 79 "two-fetch"
|
||
32b is the value at addr. See: "number"
|
||
|
||
2CONSTANT 32b -- M,83 "two-constant"
|
||
A defining word executed in the form:
|
||
32b 2CONSTANT <name>
|
||
____
|
||
Creates a dictionary entry for <name> so that when <name> is
|
||
____ ____
|
||
later executed, 32b will be left on the stack.
|
||
|
||
2DROP 32b -- 79 "two-drop"
|
||
32b is removed from the stack.
|
||
|
||
2DUP 32b -- 32b 32b 79 "two-dupe"
|
||
Duplicate 32b.
|
||
|
||
2OVER 32b1 32b2 -- 32b1 32b2 32b3 79 "two-over"
|
||
32b3 is a copy of 32b1.
|
||
|
||
2ROT 32b1 32b2 32b3 -- 32b2 32b3 32b1 79 "two-rote"
|
||
The top three double numbers on the stack are rotated,
|
||
bringing the third double number number to the top of the
|
||
stack.
|
||
|
||
2SWAP 32b1 32b2 -- 32b2 32b1 79 "two-swap"
|
||
The top two double numbers are exchanged.
|
||
|
||
2VARIABLE -- M,79 "two-variable"
|
||
A defining word executed in the form:
|
||
2VARIABLE <name>
|
||
____
|
||
A dictionary entry for <name> is created and four bytes are
|
||
____
|
||
ALLOTted in its parameter field. This parameter field is to
|
||
be used for contents of the variable. The application is
|
||
responsible for initializing the contents of the variable
|
||
which it creates. When <name> is later executed, the
|
||
____
|
||
address of its parameter field is placed on the stack. See:
|
||
VARIABLE
|
||
|
||
D+ wd1 wd2 -- wd3 79
|
||
See the complete definition in the Required Word Set.
|
||
|
||
D- wd1 wd2 -- wd3 79 "d-minus"
|
||
wd3 is the result of subtracting wd2 from wd1.
|
||
|
||
D. d -- M,79 "d-dot"
|
||
The absolute value of d is displayed in a free field format.
|
||
A leading negative sign is displayed if d is negative.
|
||
|
||
|
||
|
||
46
|
||
|
||
|
||
|
||
|
||
|
||
13. DOUBLE NUMBER EXTENSION WORD SET
|
||
|
||
|
||
D.R d +n -- M,83 "d-dot-r"
|
||
d is converted using the value of BASE and then displayed
|
||
right aligned in a field +n characters wide. A leading
|
||
minus sign is displayed if d is negative. If the number of
|
||
characters required to display d is greater than +n, an
|
||
error condition exists. See: "number conversion"
|
||
|
||
D0= wd -- flag 83 "d-zero-equals"
|
||
flag is true if wd is zero.
|
||
|
||
D2/ d1 -- d2 83 "d-two-divide"
|
||
d2 is the result of d1 arithmetically shifted right one bit.
|
||
The sign is included in the shift and remains unchanged.
|
||
|
||
D< d1 d2 -- flag 83
|
||
See the complete definition in the Required Word Set.
|
||
|
||
D= wd1 wd2 -- flag 83 "d-equal"
|
||
flag is true if wd1 equals wd2.
|
||
|
||
DABS d -- ud 79 "d-absolute"
|
||
ud is the absolute value of d. If d is -2,147,483,648 then
|
||
ud is the same value. See: "arithmetic, two's complement"
|
||
|
||
DMAX d1 d2 -- d3 79 "d-max"
|
||
d3 is the greater of d1 and d2.
|
||
|
||
DMIN d1 d2 -- d3 79 "d-min"
|
||
d3 is the lesser of d1 and d2.
|
||
|
||
DNEGATE d1 -- d2 79
|
||
See the complete definition in the Required Word Set.
|
||
|
||
DU< ud1 ud2 -- flag 83 "d-u-less"
|
||
flag is true if ud1 is less than ud2. Both numbers are
|
||
unsigned.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
47
|
||
|
||
|
||
|
||
|
||
|
||
14. ASSEMBLER EXTENSION WORD SET
|
||
|
||
|
||
|
||
|
||
14. ASSEMBLER EXTENSION WORD SET
|
||
|
||
|
||
|
||
14.1 The Assembler Extension Word Set Layers
|
||
|
||
|
||
Nucleus layer
|
||
|
||
none
|
||
|
||
|
||
Device layer
|
||
|
||
none
|
||
|
||
|
||
Interpreter layer
|
||
|
||
ASSEMBLER
|
||
|
||
|
||
Compiler layer
|
||
|
||
;CODE CODE END-CODE
|
||
|
||
|
||
14.2 Assembler Extension Word Set Usage
|
||
|
||
Because of the system dependent nature of machine language
|
||
programming, a Standard Program cannot use CODE or ;CODE .
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
48
|
||
|
||
|
||
|
||
|
||
|
||
14. ASSEMBLER EXTENSION WORD SET
|
||
|
||
|
||
|
||
|
||
|
||
14.3 The Assembler Extension Word Set Glossary
|
||
|
||
;CODE -- C,I,79 "semi-colon-
|
||
sys1 -- sys2 (compiling) code"
|
||
Used in the form:
|
||
: <namex> ... <create> ... ;CODE ... END-CODE
|
||
_____ ______
|
||
Stops compilation, terminates the defining word <namex> and
|
||
_____
|
||
executes ASSEMBLER. When <namex> is executed in the form:
|
||
_____
|
||
<namex> <name>
|
||
_____ ____
|
||
to define the new <name>, the execution address of <name>
|
||
____ ____
|
||
will contain the address of the code sequence following the
|
||
;CODE in <namex>. Execution of any <name> will cause this
|
||
_____ ____
|
||
machine code sequence to be executed. sys1 is balanced with
|
||
its corresponding : . sys2 is balanced with its
|
||
corresponding END-CODE . See: CODE DOES>
|
||
|
||
ASSEMBLER -- 83
|
||
Execution replaces the first vocabulary in the search order
|
||
with the ASSEMBLER vocabulary. See: VOCABULARY
|
||
|
||
CODE -- sys M,83
|
||
A defining word executed in the form:
|
||
CODE <name> ... END-CODE
|
||
____
|
||
Creates a dictionary entry for <name> to be defined by a
|
||
____
|
||
following sequence of assembly language words. Words thus
|
||
defined are called code definitions. This newly created
|
||
word definition for <name> cannot be found in the dictionary
|
||
____
|
||
until the corresponding END-CODE is successfully processed
|
||
(see: END-CODE ). Executes ASSEMBLER . sys is balanced
|
||
with its corresponding END-CODE .
|
||
|
||
END-CODE sys -- 79 "end-code"
|
||
Terminates a code definition and allows the <name> of the
|
||
____
|
||
corresponding code definition to be found in the dictionary.
|
||
sys is balanced with its corresponding CODE or ;CODE . See:
|
||
CODE
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
49
|
||
|
||
|
||
|
||
|
||
|
||
15. THE SYSTEM EXTENSION WORD SET
|
||
|
||
|
||
|
||
|
||
15. THE SYSTEM EXTENSION WORD SET
|
||
|
||
|
||
|
||
15.1 The System Extension Word Set Layers
|
||
|
||
|
||
Nucleus layer
|
||
|
||
BRANCH ?BRANCH
|
||
|
||
|
||
Device layer
|
||
|
||
none
|
||
|
||
|
||
Interpreter layer
|
||
|
||
CONTEXT CURRENT
|
||
|
||
|
||
Compiler layer
|
||
|
||
<MARK <RESOLVE >MARK >RESOLVE
|
||
|
||
|
||
15.2 System Extension Word Set Usage
|
||
|
||
After BRANCH or ?BRANCH is compiled, >MARK or <RESOLVE is
|
||
executed. The addr left by >MARK is passed to >RESOLVE . The
|
||
addr left by <MARK is passed to <RESOLVE . For example:
|
||
: IF COMPILE ?BRANCH >MARK ; IMMEDIATE
|
||
: THEN >RESOLVE ; IMMEDIATE
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
50
|
||
|
||
|
||
|
||
|
||
|
||
15. THE SYSTEM EXTENSION WORD SET
|
||
|
||
|
||
|
||
|
||
|
||
15.3 The System Extension Word Set Glossary
|
||
|
||
<MARK -- addr C,83 "backward-mark"
|
||
Used at the destination of a backward branch. addr is
|
||
typically only used by <RESOLVE to compile a branch address.
|
||
|
||
<RESOLVE addr -- C,83"backward-resolve"
|
||
Used at the source of a backward branch after either BRANCH
|
||
or ?BRANCH . Compiles a branch address using addr as the
|
||
destination address.
|
||
|
||
>MARK -- addr C,83 "forward-mark"
|
||
Used at the source of a forward branch. Typically used
|
||
after either BRANCH or ?BRANCH . Compiles space in the
|
||
dictionary for a branch address which will later be resolved
|
||
by >RESOLVE .
|
||
|
||
>RESOLVE addr -- C,83"forward-resolve"
|
||
Used at the destination of a forward branch. Calculates the
|
||
branch address (to the current location in the dictionary)
|
||
using addr and places this branch address into the space
|
||
left by >MARK .
|
||
|
||
?BRANCH flag -- C,83"question-branch"
|
||
When used in the form: COMPILE ?BRANCH a conditional
|
||
branch operation is compiled. See BRANCH for further
|
||
details. When executed, if flag is false the branch is
|
||
performed as with BRANCH . When flag is true execution
|
||
continues at the compilation address immediately following
|
||
the branch address.
|
||
|
||
BRANCH -- C,83
|
||
When used in the form: COMPILE BRANCH an unconditional
|
||
branch operation is compiled. A branch address must be
|
||
compiled immediately following this compilation address.
|
||
The branch address is typically generated by following
|
||
BRANCH with <RESOLVE or >MARK .
|
||
|
||
CONTEXT -- addr U,79
|
||
The address of a variable which determines the dictionary
|
||
search order.
|
||
|
||
CURRENT -- addr U,79
|
||
The address of a variable specifying the vocabulary in which
|
||
new word definitions are appended.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
51
|
||
|
||
|
||
|
||
|
||
|
||
16. CONTROLLED REFERENCE WORDS
|
||
|
||
|
||
|
||
|
||
16. CONTROLLED REFERENCE WORDS
|
||
|
||
|
||
The Controlled Reference Words are word definitions which,
|
||
although not required, cannot be present with a non-standard
|
||
definition in the vocabulary FORTH of a Standard System. These
|
||
words have present usage and/or are candidates for future
|
||
standardization.
|
||
|
||
--> -- I,M,79 "next-block"
|
||
-- (compilation)
|
||
Continue interpretation on the next sequential block. May
|
||
be used within a colon definition that crosses a block
|
||
boundary.
|
||
|
||
.R n +n -- M,83 "dot-r"
|
||
n is converted using BASE and then displayed right aligned
|
||
in a field +n characters wide. A leading minus sign is
|
||
displayed if n is negative. If the number of characters
|
||
required to display n is greater than +n, an error condition
|
||
exists. See: "number conversion"
|
||
|
||
2* w1 -- w2 83 "two-times"
|
||
w2 is the result of shifting w1 left one bit. A zero is
|
||
shifted into the vacated bit position.
|
||
|
||
BL -- 32 79 "b-l"
|
||
Leave the ASCII character value for space (decimal 32).
|
||
|
||
BLANK addr u -- 83
|
||
u bytes of memory beginning at addr are set to the ASCII
|
||
character value for space. No action is taken if u is zero.
|
||
|
||
C, 16b -- 83 "c-comma"
|
||
ALLOT one byte then store the least-significant 8 bits of
|
||
16b at HERE 1- .
|
||
|
||
DUMP addr u -- M,79
|
||
List the contents of u addresses starting at addr. Each
|
||
line of values may be preceded by the address of the first
|
||
value.
|
||
|
||
EDITOR -- 83
|
||
Execution replaces the first vocabulary in the search order
|
||
with the EDITOR vocabulary. See: VOCABULARY
|
||
|
||
EMPTY-BUFFERS -- M,79 "empty-buffers"
|
||
Unassign all block buffers. UPDATEed blocks are not written
|
||
to mass storage. See: BLOCK
|
||
|
||
|
||
|
||
|
||
|
||
|
||
52
|
||
|
||
|
||
|
||
|
||
|
||
16. CONTROLLED REFERENCE WORDS
|
||
|
||
|
||
END flag -- C,I,79
|
||
sys -- (compiling)
|
||
A synonym for UNTIL .
|
||
|
||
ERASE addr u -- 79
|
||
u bytes of memory beginning at addr are set to zero. No
|
||
action is taken if u is zero.
|
||
|
||
HEX -- 29
|
||
Set the numeric input-output conversion base to sixteen.
|
||
|
||
INTERPRET -- M,83
|
||
Begin text interpretation at the character indexed by the
|
||
contents of >IN relative to the block number contained in
|
||
BLK , continuing until the input stream is exhausted. If
|
||
BLK contains zero, interpret characters from the text input
|
||
buffer. See: "input stream"
|
||
|
||
K -- w C,83
|
||
w is a copy of the index of the second outer loop. May only
|
||
be used within a nested DO-LOOP or DO-+LOOP in the form, for
|
||
example:
|
||
DO ... DO ... DO ... K ... LOOP ... +LOOP ... LOOP
|
||
|
||
LIST u -- M,79
|
||
The contents of screen u are displayed. SCR is set to u.
|
||
See: BLOCK
|
||
|
||
OCTAL -- 83
|
||
Set the numeric input-output conversion base to eight.
|
||
|
||
OFFSET -- addr U,83
|
||
The address of a variable that contains the offset added to
|
||
the block number on the stack by BLOCK or BUFFER to
|
||
determine the actual physical block number.
|
||
|
||
QUERY -- M,83
|
||
Characters are received and transferred into the memory area
|
||
addressed by TIB . The transfer terminates when either a
|
||
"return" is received or the number of characters transferred
|
||
reaches the size of the area addressed by TIB . The values
|
||
of >IN and BLK are set to zero and the value of #TIB is set
|
||
to the value of SPAN . WORD may be used to accept text from
|
||
this buffer. See: EXPECT "input stream"
|
||
|
||
RECURSE -- C,I,83
|
||
-- (compiling)
|
||
Compile the compilation address of the definition being
|
||
compiled to cause the definition to later be executed
|
||
recursively.
|
||
|
||
SCR -- addr U,79 "s-c-r"
|
||
The address of a variable containing the number of the
|
||
screen most recently LISTed.
|
||
|
||
|
||
|
||
53
|
||
|
||
|
||
|
||
|
||
|
||
16. CONTROLLED REFERENCE WORDS
|
||
|
||
|
||
SP@ -- addr 79 "s-p-fetch"
|
||
addr is the address of the top of the stack just before SP@
|
||
was executed.
|
||
|
||
THRU u1 u2 -- M,83
|
||
Load consecutively the blocks from u1 through u2.
|
||
|
||
U.R u +n -- M,83 "u-dot-r"
|
||
u is converted using the value of BASE and then displayed as
|
||
an unsigned number right aligned in a field +n characters
|
||
wide. If the number of characters required to display u is
|
||
greater than +n, an error condition exists. See: "number
|
||
conversion"
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
54
|
||
|
||
|
||
|
||
|
||
|
||
A. STANDARDS TEAM MEMBERSHIP
|
||
|
||
|
||
|
||
|
||
APPENDIX A. STANDARDS TEAM MEMBERSHIP
|
||
|
||
|
||
|
||
A.1 Standard Team Membership: Members
|
||
|
||
The following is a list in alphabetical order of the people who
|
||
are FORTH Standards Team Members. These names are provided to
|
||
indicate the texture and make-up of the team itself. Where
|
||
appropriate, the official capacity of individuals is also
|
||
indicated.
|
||
|
||
Paul Bartholdi, Sauverny, Switzerland
|
||
Robert Berkey, Palo Alto, California USA Treasurer
|
||
David Boulton, Redwood City, California USA
|
||
John Bumgarner, Morgan Hill, California USA
|
||
Don Colburn, Rockville, Maryland USA
|
||
James T. Currie, Jr., Blacksburg, Virginia USA
|
||
Thomas B. Dowling, Lowell, Massachusetts USA
|
||
William S. Emery, Malibu, California USA
|
||
Lawrence P. Forsley, Rochester, New York USA
|
||
Kim R. Harris, Palo Alto, California USA Referee
|
||
John S. James, Los Gatos, California USA
|
||
Guy M. Kelly, La Jolla, California USA Chair
|
||
Thea Martin, Rochester, New York USA
|
||
Michael McNeil, Scotts Valley, California USA
|
||
Robert E. Patten, Modesto, California USA
|
||
Michael Perry, Berkeley, California USA
|
||
David C. Petty, Cambridge, Massachusetts USA
|
||
William F. Ragsdale, Hayward, California USA
|
||
Elizabeth D. Rather, Hermosa Beach, California USA
|
||
Dean Sanderson, Hermosa Beach, California USA Referee
|
||
Klaus Schleisiek, Hamburg, W-Germany
|
||
George W. Shaw II, Hayward, California USA Referee
|
||
Robert L. Smith, Palo Alto, California USA Secretary
|
||
Michael K. Starling, Elkview, West Virginia USA
|
||
John K. Stevenson, Portland, Oregon USA
|
||
Glenn S. Tenney, San Mateo, California USA Referee
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
55
|
||
|
||
|
||
|
||
|
||
|
||
A. STANDARDS TEAM MEMBERSHIP
|
||
|
||
|
||
|
||
|
||
|
||
A.2 FORTH Standards Team Sponsors
|
||
|
||
The following is a list in alphabetical order of individuals and
|
||
organizations who have contributed funds and other assistance to
|
||
aid the word of the FST and deserve recognition for their
|
||
involvement. FST sponsors have no duties or responsibilities in
|
||
the FST, but they receive copies of proposals and comments
|
||
considered at a formal meeting, and drafts and adopted standards
|
||
prepared as a result of that meeting.
|
||
|
||
Creative Solutions Inc., 4801 Randolph Rd., Rockville, MD 20852
|
||
USA
|
||
|
||
Fantasia Systems Inc., 1059 Alameda de las Pulgas, Belmont, CA
|
||
94002 USA
|
||
|
||
FORTH, Inc., 2309 Pacific Coast Highway, Hermosa Beach, CA 90254
|
||
USA
|
||
|
||
FORTH Interest Group Inc., P.O. Box 1105, San Carlos, CA 94070
|
||
USA
|
||
|
||
Forthright Enterprises, P.O. Box 50911, Palo Alto, CA 94020 USA
|
||
|
||
Glen Haydon Enterprises, Box 439 Rt. 2, La Honda, CA 94020 USA
|
||
|
||
John K. Gotwals, W. Lafayette, IN USA
|
||
|
||
John D. Hall, Oakland, CA USA
|
||
|
||
Hartronix, Inc., 1201 N. Stadem, Tempe, AZ 85281 USA
|
||
|
||
Hewlett-Packard Corvallis Div., 1000 NE Circle Blvd., Corvallis,
|
||
OR 97330 USA
|
||
|
||
Information Unlimited Software, Inc., 2401 Marinship, Sausalito,
|
||
CA 94965 USA
|
||
|
||
Henry H. Laxen, 1259 Cornell Avenue, Berkeley, CA 94705 USA
|
||
|
||
Laxen & Harris, Inc.
|
||
|
||
George B. Lyons, 280 Henderson Street, Jersey Cit, NJ 07302 USA
|
||
|
||
C. Kevin McCabe, Chicago, IL USA
|
||
|
||
MicroMotion, 12077 Wilshire Blvd #506, Los Angeles, CA 90025 USA
|
||
|
||
Bruce R. Montague, Monterey, CA USA
|
||
|
||
Mountain View Press, P.O. Box 4659, Mountain View, CA 94040 USA
|
||
|
||
|
||
|
||
56
|
||
|
||
|
||
|
||
|
||
|
||
A. STANDARDS TEAM MEMBERSHIP
|
||
|
||
|
||
Michael A. Perry, Berkeley, CA USA
|
||
|
||
Robert Berkey Services, 2334 Dumbarton Ave., Palo Alto, CA 94303
|
||
USA
|
||
|
||
Royal Greenwich Observatory, Herstmonsioux Castle, Eastbourne,
|
||
England
|
||
|
||
Shaw Laboratories, Ltd., 24301 Southland Drive #216, Hayward, CA
|
||
94545 USA
|
||
|
||
Sygnetron Protection Systems, Inc., 2103 Greenspring, Timonium,
|
||
MD 21093 USA
|
||
|
||
Telelogic Inc., 196 Broadway, Cambridge, MA 02139 USA
|
||
|
||
UNISOFT, P.O. Box 2644, New Carrollton, MD 20784 USA
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
57
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
|
||
|
||
APPENDIX B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
The Uncontrolled Reference Word Set contains glossary definitions
|
||
which are included for public reference of words that have past
|
||
or present usage and/or are candidates for future
|
||
standardization. No recommendation is made that these words be
|
||
included in a system.
|
||
|
||
No restrictions are placed on the definition or usage of
|
||
uncontrolled words. However, use of these names for procedures
|
||
differing from the given definitions is discouraged.
|
||
|
||
!BITS 16b1 addr 16b2 -- "store-bits"
|
||
Store the value of 16b1 masked by 16b2 into the equivalent
|
||
masked part of the contents of addr, without affecting bits
|
||
outside the mask.
|
||
|
||
** n1 n2 -- n3 "power"
|
||
n3 is the value of n1 to the power n2.
|
||
|
||
+BLOCK w -- u "plus-block"
|
||
u is the sum of w plus the number of the block being
|
||
interpreted.
|
||
|
||
-' -- addr false "dash-tick"
|
||
-- true
|
||
Used in the form:
|
||
-' <name>
|
||
____
|
||
Leave the parameter field of <name> beneath zero (false) if
|
||
____
|
||
<name> can be found in the search order; leave only true if
|
||
____
|
||
not found.
|
||
|
||
-MATCH addr1 +n1 addr2 +n2 -- addr3 flag "dash-match"
|
||
Attempt to find the +n2-length text string beginning at
|
||
addr2 somewhere in the +n1-length text string beginning at
|
||
addr1. Return the last+1 address addr3 of the match point
|
||
and a flag which is zero if a match exists.
|
||
|
||
-TEXT addr1 +n1 addr2 -- n2 "dash-text"
|
||
Compare two strings over the length +n1 beginning at addr1
|
||
and addr2. Return zero if the strings are equal. If
|
||
unequal, return n2, the difference between the last
|
||
characters compared: addr1(i) - addr2(i).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
58
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
/LOOP +n -- C,I "up-loop"
|
||
sys -- (compiling)
|
||
A do-loop terminating word. The loop index is incremented
|
||
by the positive value +n. If the unsigned magnitude of the
|
||
resultant index is greater than the limit, then the loop is
|
||
terminated, otherwise execution returns to the corresponding
|
||
DO . The comparison is unsigned magnitude. sys is balanced
|
||
with its corresponding DO . See: DO
|
||
|
||
1+! addr -- "one-plus-store"
|
||
Add one to the 16-bit contents at addr.
|
||
|
||
1-! addr -- "one-minus-store"
|
||
Subtract one from the 16-bit contents at addr.
|
||
|
||
;: -- addr C,I"semi-colon-colon"
|
||
Used to specify a new defining word:
|
||
: <namex> <name>
|
||
____
|
||
When <namex> is executed, it creates an entry for the new
|
||
word <name>. Later execution of <name> will execute the
|
||
____ ____
|
||
sequence of words between ;: and ; , with the address of the
|
||
first (if any) parameters associated with <name> on the
|
||
____
|
||
stack.
|
||
|
||
;S -- Interpret only"semi-s"
|
||
Stop interpretation of a block.
|
||
|
||
<> w1 w2 -- flag "not-equal"
|
||
flag is true if w1 is not equal to w2.
|
||
|
||
<BUILDS -- "builds"
|
||
Used in conjunction with DOES> in defining words, in the
|
||
form:
|
||
: <namex> ... <BUILDS ... DOES> ... ;
|
||
and then:
|
||
<namex> <name>
|
||
____
|
||
|
||
When <namex> executes, <BUILDS creates a dictionary entry
|
||
for the new <name>. The sequence of words between <BUILDS
|
||
____
|
||
and DOES> established a parameter field for <name>. When
|
||
____
|
||
<name> is later executed, the sequence of words following
|
||
____
|
||
DOES> will be executed, with the parameter field address of
|
||
<name> on the data stack.
|
||
____
|
||
|
||
<CMOVE addr1 addr2 u -- "reverse-c-move"
|
||
A synonym for CMOVE> .
|
||
|
||
>< 16b1 -- 16b2 "byte-swap"
|
||
Swap the high and low bytes within 16b1.
|
||
|
||
>MOVE< addr1 addr2 u -- "byte-swap-move"
|
||
Move u bytes beginning at addr1 to the memory beginning at
|
||
addr2. During this move, the order of each byte pair is
|
||
reversed.
|
||
|
||
|
||
|
||
59
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
@BITS addr 16b1 -- 16b2 "fetch-bits"
|
||
Return the 16-bits at addr masked by 16b1.
|
||
|
||
AGAIN -- C,I
|
||
sys -- (compiling)
|
||
Effect an unconditional jump back to the start of a BEGIN-
|
||
AGAIN loop. sys is balanced with its corresponding BEGIN .
|
||
See: BEGIN
|
||
|
||
ASCII -- char I,M "as-key"
|
||
-- (compiling)
|
||
Used in the form:
|
||
ASCII ccc
|
||
___
|
||
where the delimiter of ccc is a space. char is the ASCII
|
||
___
|
||
character value of the first character in ccc. If
|
||
___
|
||
interpreting, char is left on the stack. If compiling,
|
||
compile char as a literal so that when the colon definition
|
||
is later executed, char is left on the stack.
|
||
|
||
ASHIFT 16b1 n -- 16b2 "a-shift"
|
||
Shift the value 16b1 arithmetically n bits left if n is
|
||
positive, shifting zeros into the least significant bit
|
||
positions. If n is negative, 16b1 is shifted right; the
|
||
sign is included in the shift and remains unchanged.
|
||
|
||
B/BUF -- 1024 "bytes-per-buffer"
|
||
A constant leaving 1024, the number of bytes per block
|
||
buffer.
|
||
|
||
BELL --
|
||
Activate a terminal bell or noise-maker as appropriate to
|
||
the device in use.
|
||
|
||
CHAIN -- M
|
||
Used in the form:
|
||
CHAIN <name>
|
||
____
|
||
Connect the CURRENT vocabulary to all definitions that might
|
||
be entered into the vocabulary <name> in the future. The
|
||
____
|
||
CURRENT vocabulary may not be FORTH or ASSEMBLER . Any
|
||
given vocabulary may only be chained once, but may be the
|
||
object of any number of chainings. For example, every user-
|
||
defined vocabulary may include the sequence:
|
||
CHAIN FORTH
|
||
|
||
CONTINUED u -- M
|
||
Continue interpretation at block u.
|
||
|
||
CUR -- addr
|
||
A variable pointing to the physical record number before
|
||
which the tape is currently positioned. REWIND sets CUR=1.
|
||
|
||
DBLOCK ud -- addr M "d-block"
|
||
Identical to BLOCK but with a 32-bit block unsigned number.
|
||
|
||
|
||
|
||
|
||
60
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
DPL -- addr U "d-p-l"
|
||
A variable containing the number of places after the
|
||
fractional point for input conversion.
|
||
|
||
FLD -- addr U "f-l-d"
|
||
A variable pointing to the field length reserved for a
|
||
number during output conversion.
|
||
|
||
H. u -- M "h-dot"
|
||
Output u as a hexadecimal integer with one trailing blank.
|
||
The current base is unchanged.
|
||
|
||
I' -- w C "i-prime"
|
||
Used within a colon definition executed only from within a
|
||
do-loop to return the corresponding loop index.
|
||
|
||
IFEND Interpret only"if-end"
|
||
Terminate a conditional interpretation sequence begun by
|
||
IFTRUE .
|
||
|
||
IFTRUE flag -- Interpret only "if-true"
|
||
Begin an:
|
||
IFTRUE ... OTHERWISE ... IFEND
|
||
conditional sequence. These conditional words operated
|
||
like:
|
||
IF ... ELSE ... THEN
|
||
except that they cannot be nested, and are to be used only
|
||
during interpretation. In conjunction with the words [ and
|
||
] the words [ and ] they may be used within a colon
|
||
definition to control compilation, although they are not to
|
||
be compiled.
|
||
|
||
INDEX u1 u2 -- M
|
||
Print the first line of each screen over the range {u1..u2}.
|
||
This displays the first line of each screen of source text,
|
||
which conventionally contains a title.
|
||
|
||
LAST -- addr U
|
||
A variable containing the address of the beginning of the
|
||
last dictionary entry made, which may not yet be a complete
|
||
or valid entry.
|
||
|
||
LINE +n -- addr M
|
||
addr is the address of the beginning of line +n for the
|
||
screen whose number is contained in SCR . The range of +n
|
||
is {0..15}.
|
||
|
||
LINELOAD +n u -- "line-load"
|
||
Begin interpretation at line +n of screen u.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
61
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
LOADS u -- M
|
||
A defining word executed in the form:
|
||
u LOADS <name>
|
||
____
|
||
When <name> is subsequently executed, block u will be
|
||
____
|
||
loaded.
|
||
|
||
MAP0 -- addr "map-zero"
|
||
A variable pointing to the first location in the tape map.
|
||
|
||
MASK n -- 16b
|
||
16b is a mask of n most-significant bits if n is positive,
|
||
or n least-significant bits if n is negative.
|
||
|
||
MOVE addr1 addr2 u --
|
||
The u bytes at address addr1 are moved to address addr2.
|
||
The data are moved such that the u bytes remaining at
|
||
address addr2 are the same data as was originally at address
|
||
addr1. If u is zero nothing is moved.
|
||
|
||
MS +n -- M "m-s"
|
||
Delay for approximately +n milliseconds.
|
||
|
||
NAND 16b1 16b2 -- 16b3
|
||
16b3 is the one's complement of the logical AND of 16b1 with
|
||
16b2.
|
||
|
||
NOR 16b1 16b2 -- 16b3
|
||
16b3 is the one's complement of the logical OR of 16b1 with
|
||
16b2.
|
||
|
||
NUMBER addr -- d
|
||
Convert the count and character string at addr, to a signed
|
||
32-bit integer, using the value of BASE . If numeric
|
||
conversion is not possible, an error condition exists. The
|
||
string may contain a preceding minus sign.
|
||
|
||
O. u -- M "o-dot"
|
||
Print u in octal format with one trailing blank. The value
|
||
in BASE is unaffected.
|
||
|
||
OTHERWISE -- Interpret only
|
||
An interpreter-level conditional word. See: IFTRUE
|
||
|
||
PAGE -- M
|
||
Clear the terminal screen or perform a form-feed action
|
||
suitable to the output device currently active.
|
||
|
||
READ-MAP -- M "read-map"
|
||
Read to the next file mark on tape constructing a
|
||
correspondence table in memory (the map) relating physical
|
||
block position to logical block number. The tape should
|
||
normally be rewound to its load point before executing READ-
|
||
MAP .
|
||
|
||
|
||
|
||
|
||
62
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
REMEMBER -- M
|
||
A defining word executed in the form:
|
||
REMEMBER <name>
|
||
____
|
||
Defines a word which, when executed, will cause <name> and
|
||
____
|
||
all subsequently defined words to be deleted from the
|
||
dictionary. <name> may be compiled into and executed from a
|
||
____
|
||
colon definition. The sequence
|
||
DISCARD REMEMBER DISCARD
|
||
provides a standardized preface to any group of transient
|
||
word definitions.
|
||
|
||
REWIND -- M
|
||
Rewind the tape to its load point, setting CUR equal to one.
|
||
|
||
ROTATE 16b1 n -- 16b2
|
||
Rotate 16b1 left n bits if n is positive, right n bits if n
|
||
is negative. Bits shifted out of one end of the cell are
|
||
shifted back in at the opposite end.
|
||
|
||
S0 -- addr U "s-zero"
|
||
A variable containing the address of the bottom of the
|
||
stack.
|
||
|
||
SET 16b addr -- M
|
||
A defining word executed in the form:
|
||
16b addr SET <name>
|
||
____
|
||
Defines a word <name> which, when executed, will cause the
|
||
____
|
||
value 16b to be stored at addr.
|
||
|
||
SHIFT 16b1 n -- 16b2
|
||
Logical shift 16b1 left n bits if n is positive, right n
|
||
bits if n is negative. Zeros are shifted into vacated bit
|
||
positions.
|
||
|
||
TEXT char -- M
|
||
Accept characters from the input stream, as for WORD , into
|
||
PAD , blank-filling the remainder of PAD to 84 characters.
|
||
|
||
USER +n -- M
|
||
A defining word executed in the form:
|
||
+n USER <name>
|
||
____
|
||
which creates a user variable <name>. +n is the offset
|
||
____
|
||
within the user area where the value for <name> is stored.
|
||
____
|
||
Execution of <name> leaves its absolute user area storage
|
||
____
|
||
address.
|
||
|
||
WORDS -- M
|
||
List the word names in the first vocabulary of the currently
|
||
active search order.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
63
|
||
|
||
|
||
|
||
|
||
|
||
B. UNCONTROLLED REFERENCE WORDS
|
||
|
||
|
||
\LOOP +n -- C,I "down-loop"
|
||
sys -- (compiling)
|
||
A do-loop terminating word. The loop index is decremented
|
||
by the positive value +n. If the unsigned magnitude of the
|
||
resultant index is less than or equal to the limit, then the
|
||
loop is terminated, otherwise execution returns to the
|
||
corresponding DO . The comparison is unsigned. sys is
|
||
balanced with its corresponding DO . See: DO
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
64
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
|
||
|
||
APPENDIX C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
Since FORTH is an extensible language and subject to evolution,
|
||
the Standard contains a section describing experimental
|
||
proposals. FORTH users are encouraged to study, implement, and
|
||
try these proposals to aid in the analysis of and the decision
|
||
for or against future adoption into the Standard. Readers are
|
||
cautioned that these proposals contain opinions and conclusions
|
||
of the authors of the proposals and that these proposals may
|
||
contain non-standard source code.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
65
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
|
||
|
||
|
||
|
||
SEARCH ORDER SPECIFICATION AND CONTROL
|
||
|
||
|
||
WILLIAM F. RAGSDALE
|
||
|
||
|
||
1 INTRODUCTION
|
||
|
||
The method of selecting the order in which the dictionary is
|
||
searched has grown from unchained vocabularies to the present use
|
||
of chained vocabularies. Many techniques are in use for
|
||
specification of the sequence in which multiple vocabularies may
|
||
be searched. In order to offer generality and yet get precision
|
||
in specification, this proposal is offered.
|
||
|
||
|
||
2 DESCRIPTION
|
||
|
||
The following functions are required:
|
||
|
||
1. Two search orders exist. CONTEXT is the group of
|
||
vocabularies searched during interpretation of text from the
|
||
input stream. CURRENT is the single vocabulary into which
|
||
new definitions are compiled, and from which FORGET
|
||
operates.
|
||
|
||
2. Empty CONTEXT to a minimum number of system words. These
|
||
are just the words to further specify the search order.
|
||
|
||
3. Add individual vocabularies into CONTEXT. The most recently
|
||
added is searched first.
|
||
|
||
4. Specify which single vocabulary will become CURRENT.
|
||
|
||
The following optional functions aid the user:
|
||
|
||
1. Display the word names of the first vocabulary in the
|
||
CONTEXT search order.
|
||
|
||
2. Display the vocabulary names comprising CURRENT and CONTEXT
|
||
search orders.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
66
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
3 ADVANTAGES
|
||
|
||
Use over the past year has demonstrated that the proposed
|
||
methods may emulate the vocabulary selection of all other
|
||
systems. The order is explicit by execution, may be interpreted
|
||
and compiled, and is obvious from the declaration. The search
|
||
order is specified at run-time rather than the time a new
|
||
vocabulary is created.
|
||
|
||
|
||
4 DISADVANTAGES
|
||
|
||
By migrating to a common structure, vendors give up one
|
||
point at which they may claim their product is better than
|
||
others. Another drawback is that the number of CONTEXT
|
||
vocabularies is fixed; older methods had an indefinite 'tree'
|
||
structure. In practice, the branching of such a structure was
|
||
very rarely greater than four.
|
||
|
||
Forth words operate in a context sensitive environment, as
|
||
word names may be redefined and have different definitions in
|
||
different vocabularies. This proposal compounds the problem. By
|
||
displaying the search order names, the user at least can readily
|
||
verify the search order.
|
||
|
||
|
||
5 IMPACT
|
||
|
||
The text of the Forth 83 Standard has been carefully chosen
|
||
for consistency and generality. However, no specification on how
|
||
the search order is developed by the user is given. This
|
||
omission is unavoidable, due to the diversity of contemporary
|
||
practice. This proposal is intended to complete the Forth 83
|
||
requirements in a fashion that exceeds all other methods.
|
||
|
||
Previously standardized words continue in their use:
|
||
VOCABULARY, FORTH, DEFINITIONS, and FORGET. However, this
|
||
proposal assumes that vocabulary names are not IMMEDIATE .
|
||
|
||
|
||
6 DEFINITIONS
|
||
|
||
Search order:
|
||
The sequence in which vocabularies are selected when
|
||
locating a word by name in the dictionary. Consists of one
|
||
transient and up to three resident vocabularies.
|
||
|
||
Transient order:
|
||
Execution of any vocabulary makes it the first vocabulary
|
||
searched, replacing the previously selected transient
|
||
vocabulary.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
67
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
Resident order:
|
||
After searching the transient order, up to three additional
|
||
vocabularies may be searched. The application program
|
||
controls this selection.
|
||
|
||
|
||
7 GLOSSARY
|
||
|
||
ONLY -- ONLY
|
||
Select just the ONLY vocabulary as both the transient
|
||
vocabulary and resident vocabulary in the search order.
|
||
|
||
FORTH -- ONLY
|
||
The name of the primary vocabulary. Execution makes FORTH
|
||
the transient vocabulary, the first in the search order, and
|
||
thus replaces the previous transient vocabulary.
|
||
|
||
ALSO -- ONLY
|
||
The transient vocabulary becomes the first vocabulary in the
|
||
resident portion of the search order. Up to the last two
|
||
resident vocabularies will also be reserved, in order,
|
||
forming the resident search order.
|
||
|
||
ORDER -- ONLY
|
||
Display the vocabulary names forming the search order in
|
||
their present search order sequence. Then show the
|
||
vocabulary into which new definitions will be placed.
|
||
|
||
WORDS -- ONLY
|
||
Display the word names in the transient vocabulary, starting
|
||
with the most recent definition.
|
||
|
||
FORGET -- ONLY
|
||
Used in the form:
|
||
FORGET <name>
|
||
____
|
||
Delete from the dictionary <name> and all words added to the
|
||
____
|
||
dictionary after <name> regardless of the vocabulary.
|
||
____
|
||
Failure to find <name> is an error condition. An error
|
||
____
|
||
condition also exists upon implicitly forgetting a
|
||
vocabulary (due to its definition after <name>).
|
||
____
|
||
|
||
DEFINITIONS -- ONLY
|
||
Select the transient vocabulary as the current vocabulary
|
||
into which subsequent definitions will be added.
|
||
|
||
SEAL -- ONLY
|
||
Delete all occurances of ONLY from the search order. The
|
||
effect is that only specified application vocabularies will
|
||
be searched.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
68
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
8 TYPICAL SOURCE CODE
|
||
|
||
0 ( ALSO ONLY 82jun12 WFR )
|
||
1 ( note the systems -FIND searches 1 to 5 vocabs in CONTEXT )
|
||
2 VOCABULARY ONLY ONLY DEFINITIONS
|
||
3 : ALSO ( slide transient into resident )
|
||
4 CONTEXT DUP 2+ 6 CMOVE> ;
|
||
5
|
||
6 HERE 2+ ] ( alter run time from usual vocabulary )
|
||
7 DOES> CONTEXT 8 ERASE DUP CONTEXT ! CONTEXT 8 + !
|
||
8 ALSO EXIT [
|
||
9 ' ONLY CFA ! ( Patch into ONLY; make NULL word )
|
||
10 CREATE X ' EXIT >BODY X ! 41088 ' X NFA ! IMMEDIATE
|
||
11 : FORTH FORTH ;
|
||
12 : DEFINITIONS DEFINITIONS ; : FORGET FORGET ;
|
||
13 : VOCABULARY VOCABULARY ; : ONLY ONLY ;
|
||
14 : WORDS WORDS ;
|
||
15
|
||
|
||
0 ( ORDER 82jun12 WFR )
|
||
1 : ORDER ( show the search order )
|
||
2 10 SPACES CONTEXT 10 OVER + SWAP
|
||
3 DO I @ ?DUP 0= ?LEAVE ID. 2 +LOOP
|
||
4 10 SPACES CURRENT @ ID. ;
|
||
5
|
||
6 ONLY FORTH ALSO DEFINITIONS
|
||
7
|
||
8
|
||
9
|
||
10
|
||
11
|
||
12
|
||
13
|
||
14
|
||
15
|
||
|
||
|
||
9 EXAMPLES OF USE
|
||
|
||
ONLY reduce search order to minimum
|
||
FORTH search FORTH then ONLY
|
||
ALSO EDITOR search EDITOR, FORTH then ONLY
|
||
DEFINITIONS new definitions will be added into the EDITOR
|
||
|
||
The same sequence would be compiled:
|
||
|
||
: SETUP ONLY FORTH ALSO EDITOR DEFINITIONS ;
|
||
|
||
|
||
10 REFERENCES
|
||
|
||
W. F. Ragsdale, The 'ONLY' Concept for Vocabularies, Proceedings
|
||
___________
|
||
of the 1982 FORML Conference, pub. Forth Interest Group.
|
||
____________________________
|
||
|
||
|
||
|
||
|
||
69
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
W. F. Ragsdale, fig-FORTH Installation Manual, Forth Interest
|
||
_____________________________
|
||
Group.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
70
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
|
||
|
||
|
||
|
||
DEFINITION FIELD ADDRESS CONVERSION OPERATORS
|
||
|
||
|
||
by
|
||
|
||
Kim R. Harris
|
||
|
||
|
||
A. INTRODUCTION
|
||
|
||
The standard provides a transportable way to obtain the
|
||
compilation address of a definition in the dictionary of a FORTH
|
||
system (cf., FIND and ' ). It also provides an operator to
|
||
convert a compilation address to its corresponding parameter
|
||
field address. However, the standard does not provide a
|
||
transportable way to convert either of these addresses to the
|
||
other fields of a definition. Since various FORTH
|
||
implementations have different dictionary structures, a standard
|
||
set of conversion operators would increase transportability and
|
||
readability.
|
||
|
||
A set of words is proposed which allows the conversion of any
|
||
definitions field address to any other.
|
||
|
||
|
||
B. GLOSSARY
|
||
|
||
In the following words, the compilation address is either the
|
||
source or the destination, so it is not indicated in the names.
|
||
|
||
>BODY addr1 -- addr2 "to-body"
|
||
addr2 is the parameter field address corresponding to the
|
||
compilation address addr1.
|
||
|
||
>NAME addr1 -- addr2 "to-name"
|
||
addr2 is the name field address corresponding to the
|
||
compilation address addr1.
|
||
|
||
>LINK addr1 -- addr2 "to-link"
|
||
addr2 is the link field address corresponding to the
|
||
compilation address addr1.
|
||
|
||
BODY> addr1 -- addr2 "from-body"
|
||
addr2 is the compilation address corresponding to the
|
||
parameter field address addr1.
|
||
|
||
NAME> addr1 -- addr2 "from-name"
|
||
addr2 is the compilation address corresponding to the name
|
||
field address addr1.
|
||
|
||
|
||
|
||
|
||
71
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
LINK> addr1 -- addr2 "from-link"
|
||
addr2 is the compilation address corresponding to the link
|
||
field address addr1.
|
||
|
||
The previous set of words is complete, but may be inefficient for
|
||
going between two fields when one is not the compilation address.
|
||
For greater efficiency, additional operators may be defined which
|
||
name both the source and destination fields.
|
||
|
||
N>LINK addr1 -- addr2 "name-to-link"
|
||
addr2 is the link field address corresponding to the name
|
||
field address addr1.
|
||
|
||
L>NAME addr1 -- addr2 "link-to-name"
|
||
addr2 is the name field address corresponding to the link
|
||
field address addr1.
|
||
|
||
|
||
C. DISCUSSION
|
||
|
||
The previous words provide a complete, consistent, and efficient
|
||
set of definition field address conversion operations. They can
|
||
be implemented in a FORTH system which uses any combination of
|
||
the following options for its dictionary structure:
|
||
|
||
Link fields first or second.
|
||
Fixed or variable length name fields.
|
||
Additional fields in the definitions structure.
|
||
|
||
Heads contiguous or separated from bodies.
|
||
|
||
Indirect, direct, subroutine, or token threaded code.
|
||
|
||
The words are compatible with this standard; their inclusion
|
||
would not require other changes to be made to the standard.
|
||
|
||
Disadvantages to including them in the standard include:
|
||
|
||
They add 6 to 8 more words to the standard.
|
||
|
||
A standard program may not use all of them since it is not
|
||
allowed to access the name or link fields. However, this
|
||
does not disqualify them from being in the standard.
|
||
|
||
If a definition's head is not in the dictionary, an error
|
||
condition would exist. In this case, what action should the
|
||
words take in an implemented system?
|
||
|
||
The author of this experimental proposal recommends that FORTH
|
||
system implementors try them and that they be included in the
|
||
System Word Set of the next FORTH standard.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
72
|
||
|
||
|
||
|
||
|
||
|
||
C. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
D. SOURCE CODE EXAMPLE
|
||
|
||
High level source code is shown below for a very simple
|
||
dictionary structure. This code assumes a FORTH system which
|
||
uses indirect threaded code, heads contiguous to bodies, and a
|
||
definition structure of the following format:
|
||
|
||
Name field, 4 bytes long, fixed length.
|
||
Link field, 2 bytes long.
|
||
Code field, 2 bytes long.
|
||
Parameter field, variable length.
|
||
|
||
: >BODY ( acf -- apf ) 2+ ;
|
||
: BODY> ( apf -- acf ) 2- ;
|
||
: >LINK ( acf -- alf ) 2- ;
|
||
: LINK> ( alf -- acf ) 2- ;
|
||
: >NAME ( acf -- anf ) 6 - ;
|
||
: NAME> ( anf -- alf ) 6 + ;
|
||
: N>LINK ( anf -- alf ) 4 + ;
|
||
: L>NAME ( alf -- anf ) 4 - ;
|
||
|
||
|
||
E. EXAMPLES OF USE
|
||
|
||
No examples are given because their use should be obvious.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
73
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
|
||
|
||
APPENDIX D.
|
||
|
||
|
||
CHARTER
|
||
|
||
of the
|
||
|
||
FORTH STANDARDS TEAM
|
||
|
||
|
||
|
||
1. Purpose and Goals
|
||
|
||
|
||
1.1 Purpose
|
||
|
||
1.1.1 This Charter establishes and guides a voluntary
|
||
membership professional organization, the FORTH Standards
|
||
Team (hereafter referred to as the "FST") and provides a
|
||
method for its operation.
|
||
|
||
|
||
1.2 Goals
|
||
|
||
1.2.1 The goal of the FST is the creation, maintenance, and
|
||
proliferation of a standard (hereafter referred to as the
|
||
"Standard") for the FORTH computer programming system and
|
||
for application programs executed by a Standard system. The
|
||
Standard shall specify requirements and constraints which
|
||
such computer software must satisfy.
|
||
|
||
1.2.2 The team shall also develop a method of
|
||
identification and labeling of FORTH implementations and
|
||
programs which conform to the Standard.
|
||
|
||
|
||
1.3 Organization
|
||
|
||
1.3.1 The FST is a voluntary membership organization with
|
||
no formal status as a legal entity. It operates by
|
||
consensus of the professional and commercial FORTH community
|
||
and conducts business by the professional discourse and
|
||
agreement of its members. It is intended that this Charter
|
||
be a guide to the operation of the FST subject to reasonable
|
||
minor digression, rather than being a rigid document under
|
||
which vested rights are granted.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
74
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
2. METHODS
|
||
|
||
|
||
2.1 Formal Meetings
|
||
|
||
2.1.1 The FST shall hold periodic formal meetings for
|
||
discussion and decisions concerning a current or future
|
||
Standard.
|
||
|
||
2.1.2 There is not specified frequency for formal meetings.
|
||
Each meeting shall be at such time and place as was decided
|
||
at the prior meeting. If a meeting cannot be held as
|
||
decided, the Chairperson may designate another time and
|
||
place.
|
||
|
||
2.1.3 The Chairperson shall send a written notice at least
|
||
sixty (60) days in advance of each formal meeting to each
|
||
voting member. A longer notification period is recommended.
|
||
It is anticipated that the continuing close coordination of
|
||
the participants, the decision at the prior formal meeting,
|
||
and publication of a meeting notice in FORTH Dimensions and
|
||
________________
|
||
other trade journals will provide sufficient notice to the
|
||
FORTH community.
|
||
|
||
2.1.4 At a formal FST meeting, there shall be general
|
||
sessions consisting of all attendees. General sessions are
|
||
for matters that are ready for discussion and decision. All
|
||
votes concerning the Standard, Charter, or FST procedures
|
||
must take place during a general session.
|
||
|
||
2.1.5 Also at formal meetings, subteams will be established
|
||
to examine groups of proposals and to prepare
|
||
recommendations for a general session. All meeting
|
||
attendees may participate in the work and voting of a
|
||
subteam. Each subteam should elect from its members a
|
||
coordinator to conduct its meetings and a reporter to record
|
||
and report its recommendations.
|
||
|
||
2.1.6 The Chairperson may publish and distribute an agenda
|
||
at or in advance of a formal meeting. As a guideline, each
|
||
day of a formal meeting begins with a general session,
|
||
followed by concurrent subteam meetings followed by another
|
||
general session.
|
||
|
||
2.1.7 In view of the voluntary nature of the FST, at least
|
||
one third of the membership is required to hold a formal
|
||
meeting. Two thirds of the number of voting members present
|
||
at the start of each day's first general session shall set
|
||
the quorum for the remainder of that day.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
75
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
2.1.8 Between formal meetings, the Chairperson may appoint
|
||
such informal working groups as is appropriate. Each group
|
||
may be given a goal and scope to direct its activities. Its
|
||
conclusions or recommendations must be given to the
|
||
Chairperson in written form.
|
||
|
||
|
||
2.2 Proposals and Comments
|
||
|
||
2.2.1 Prior to each formal meeting, the Chairperson may
|
||
solicit submission of comments and proposals for changes,
|
||
additions, or deletions to the then-current Standard, the
|
||
draft Standard or this Charter. A cutoff date may be
|
||
specified for the submission of such proposals.
|
||
|
||
2.2.2 A considerable amount of information must accompany
|
||
each proposal to help FST members analyze the proposal.
|
||
Therefore, submission of proposals and comments shall be
|
||
according to the format and instructions shown in the
|
||
"Proposal/Comment Form" included as an Appendix to this
|
||
Standard. Any proposal not in the appropriate form or
|
||
received after the cutoff date may not be considered unless
|
||
the Chairperson deems it to be of sufficient significance.
|
||
|
||
2.2.3 Unsolicited proposals and comments by volunteers are
|
||
acknowledged as valuable. Any individual or group may
|
||
submit proposals and/or comments concerning the Standard or
|
||
this Charter. These should be sent to the official address
|
||
of the FST. Properly formatted proposals and comments are
|
||
preferred. The author or a representative should plan to
|
||
attend the next formal meeting to emphasize, support, and
|
||
possibly modify the proposals.
|
||
|
||
2.2.4 Since the quantity of proposals and comments may
|
||
exceed the number for which there is time to be voted upon,
|
||
submission of a proposal does not automatically mean that it
|
||
will be voted upon at the next formal FST meeting. The
|
||
Chairperson or some members appointed by the Chairperson or
|
||
elected by the voting members may screen and organize the
|
||
received proposals and comments for voting upon at the next
|
||
formal meeting.
|
||
|
||
2.2.5 To allow reflection and examination, proposals and
|
||
comments shall be distributed to FST voting members and
|
||
sponsors in advance of a formal meeting. Proposals and
|
||
comments not distributed in advance, including proposals
|
||
made during a formal meeting, may be considered at the
|
||
discretion of the Chairperson.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
76
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
2.3 Draft Standard
|
||
|
||
After a formal meeting, the referees and officers of the FST
|
||
shall prepare a draft Standard for review by the then-
|
||
current FST voting members. The referees and officers shall
|
||
consolidate proposals accepted by vote during the meeting,
|
||
resolve any ambiguities or problems, and incorporate these
|
||
changes with the text of the previous Standard or draft
|
||
Standard.
|
||
|
||
|
||
2.4 Standard
|
||
|
||
2.4.1 The referees and officers may, by near unanimous
|
||
decision (not more than one no vote), declare the draft
|
||
Standard, as mentioned in the previous paragraph, as being
|
||
the proposed Standard.
|
||
|
||
2.4.2 A proposed Standard shall be distributed to all FST
|
||
voting members for a mail ballot. This ballot shall be
|
||
based solely on the text of the proposed Standard as
|
||
distributed.
|
||
|
||
2.4.3 Each ballot returned shall be signed by the voting
|
||
member submitting it. An affirmative vote of at least two
|
||
thirds of the voting members shall adopt the document. Such
|
||
adoption makes the draft Standard the current, official FST
|
||
Standard which supersedes all prior Standards.
|
||
|
||
|
||
2.5 Charter
|
||
|
||
2.5.1 At a formal FST meeting, the charter may be amended
|
||
by a simple majority of voting members present provided that
|
||
at least one third of all voting members are present; such
|
||
amendments become effective at the end of the current formal
|
||
meeting.
|
||
|
||
2.5.2 At other than a formal FST meeting, the charter may
|
||
be amended by a simple majority of all voting members, such
|
||
vote to be taken by signed mail ballots.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
77
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
3. MEMBERSHIP
|
||
|
||
|
||
3.1 General
|
||
|
||
Membership in the FST is a privilege, not a right. An
|
||
invitation for voting membership may be extended to those
|
||
who the FST feels can contribute to the goals of the
|
||
Standard and the FST. There are several classes of
|
||
participation in the efforts of the FST. Membership in each
|
||
class has no specified term but continues from the time when
|
||
membership is initiated to the conclusion of the next formal
|
||
meeting.
|
||
|
||
|
||
3.2 Voting Members
|
||
|
||
3.2.1 Voting members are individuals who are elected into
|
||
such membership at the concluding session of a formal FST
|
||
meeting. Any voting member who resigns between formal
|
||
meetings shall not be replaced until the membership
|
||
elections at the conclusion of the next formal meeting. A
|
||
newly elected voting member gains voting rights only after
|
||
all voting members have been elected. A significant
|
||
professional FORTH background is required of voting members.
|
||
|
||
3.2.2 Each voting member present at a formal meeting shall
|
||
indicate in writing his or her desire to continue as a
|
||
voting member. Only these voting members can vote in a
|
||
general session of a formal meeting on any matters affecting
|
||
the Standard or the Charter and on the election of all
|
||
voting members.
|
||
|
||
3.2.3 Voting members are elected by a simple majority of
|
||
those voting members present. The number of voting members
|
||
shall be limited to thirty (30). Individuals eligible to be
|
||
elected are selected from each of the following ordered
|
||
categories in order, until the number of voting members
|
||
reaches the limit.
|
||
|
||
3.2.3.1 Category 1: current voting member who have
|
||
actively participated in at least two days of a formal
|
||
meeting. Voting members are expected to actively
|
||
participate in subteam meetings and all general
|
||
sessions.
|
||
|
||
3.2.3.2 Category 2: current voting members who are
|
||
not eligible by Category 1, but who have requested in
|
||
writing that his or her voting membership be
|
||
maintained.
|
||
|
||
3.2.3.3 Category 3: eligible candidates. Eligible
|
||
candidates will be presented to the voting members then
|
||
elected as follows:
|
||
|
||
|
||
|
||
78
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
3.2.3.3.1 If the number of eligible candidates
|
||
does not exceed the number of openings for voting
|
||
membership, each candidate is voted upon and
|
||
accepted by a simple majority.
|
||
|
||
3.2.3.3.2 If the number of eligible candidates
|
||
does exceed the number of openings for voting
|
||
membership, candidates will be voted upon by
|
||
ballot whereby each voting member may vote for up
|
||
to the number of openings remaining. Those
|
||
candidates receiving the most votes will be
|
||
elected until there are no more openings for
|
||
voting membership.
|
||
|
||
|
||
3.3 Candidates
|
||
|
||
3.3.1 Candidates are individuals who desire to actively
|
||
participate in and support the FST by becoming voting
|
||
members.
|
||
|
||
3.3.2 To be eligible, each Candidate must: declare in
|
||
writing to the secretary at the first general session of a
|
||
formal FST meeting that he or she is a Candidate, actively
|
||
participate in subteam meetings and all general sessions at
|
||
a formal FST meeting, and have a significant professional
|
||
background in FORTH. The Chairperson may request
|
||
information or ask questions of any candidate to determine
|
||
his or her technical knowledge and experience. Candidates
|
||
are expected to submit proposals, participate in the
|
||
discussions of the formal meeting, and contribute to the
|
||
work and voting of subteams.
|
||
|
||
|
||
3.4 Observers
|
||
|
||
3.4.1 Observers are individuals who attend a formal meeting
|
||
but are neither voting members nor candidates. At the
|
||
discretion of the Chairperson, they may contribute to the
|
||
discussion at general sessions and to the work of subteams.
|
||
The number of observers allowed at a formal meeting may be
|
||
limited by the Chairperson.
|
||
|
||
|
||
3.5 FST Sponsors
|
||
|
||
3.5.1 FST sponsors are individuals or organizations who
|
||
contribute funds and other assistance to aid the work of the
|
||
FST. FST sponsors have no duties or responsibilities in the
|
||
FST, but they will receive copies of proposals and comments
|
||
considered at a formal meeting, and drafts and adopted
|
||
standards prepared as a result of that meeting.
|
||
|
||
|
||
|
||
|
||
|
||
79
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
3.5.3 FST sponsorship exists from the end of one formal
|
||
meeting to the end of the next formal meeting.
|
||
|
||
3.5.3 Qualification of FST sponsors may be determined by a
|
||
simple majority vote at a formal FST meeting. If no such
|
||
qualification exist, the Chairperson may specify
|
||
qualifications, including the amount of financial
|
||
contributions, which will remain in effect until the next
|
||
formal FST meeting.
|
||
|
||
|
||
4. OFFICERS
|
||
|
||
|
||
4.1 General
|
||
|
||
There shall be four types of elected officers of the FST:
|
||
the Chairperson, the Secretary, the Treasurer, and one or
|
||
more Referees. Each officer shall be elected at a formal
|
||
meeting of the FST and serve until the next formal meeting.
|
||
|
||
|
||
4.2 Vacancies
|
||
|
||
If any office other than the Chairperson becomes vacant
|
||
between formal meetings, the Chairperson may appoint a
|
||
replacement. If the office of the Chairperson becomes
|
||
vacant between formal meetings, a new Chairperson shall be
|
||
elected by an informal majority vote of the remaining
|
||
officers. At any formal meeting, any officer, including the
|
||
Chairperson, may be replaced by a simple majority vote of
|
||
the voting members present at that meeting.
|
||
|
||
|
||
4.3 Chairperson
|
||
|
||
4.3.1 The Chairperson is responsible for governing the
|
||
general business of the FST. He or she is responsible for
|
||
implementing the FST's Charter and any other requirements
|
||
specified by the Standard.
|
||
|
||
4.3.2 The Chairperson's term of office shall be from the
|
||
conclusion of the formal meeting at which he or she is
|
||
elected to the conclusion of the next formal meeting. The
|
||
election of a Chairperson is held at the concluding general
|
||
session of a formal meeting after the election of voting
|
||
members; hence, newly elected voting members may vote for
|
||
the Chairperson. Only voting members are eligible to be
|
||
elected Chairperson.
|
||
|
||
4.3.3 The Chairperson shall conduct each formal meeting.
|
||
In general, the meetings will follow the current Robert's
|
||
________
|
||
Rules of Order; however, the Chairperson may determine the
|
||
______________
|
||
specific rules for a formal meeting.
|
||
|
||
|
||
|
||
80
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
4.3.4 Any matter needing a decision between formal meetings
|
||
not specified by this Charter shall be decided by the
|
||
Chairperson.
|
||
|
||
4.3.5 The Chairperson has duties and responsibilities
|
||
specified elsewhere in this Charter.
|
||
|
||
|
||
4.4 Secretary
|
||
|
||
4.4.1 The Secretary is responsible for recording the
|
||
activities and results of the FST.
|
||
|
||
4.4.2 The Secretary is elected at the first general session
|
||
of a formal meeting and serves until a Secretary is elected
|
||
at the beginning of the next formal meeting.
|
||
|
||
4.4.3 The Secretary has many responsibilities.
|
||
|
||
4.4.3.1 The Secretary is responsible for collecting,
|
||
maintaining, and archiving the official copies of the
|
||
Standard, the Charter, all other FST documents,
|
||
correspondence, and lists of the FST members of each class.
|
||
|
||
4.4.3.2 During a formal meeting, the Secretary is
|
||
responsible for:
|
||
|
||
(a) Keeping the minutes of the general sessions,
|
||
including all votes taken. For votes affecting the
|
||
Standard or Charter, he or she shall: record the
|
||
number of voting members present, determine if a quorum
|
||
is present, determine the number of affirmative votes
|
||
required for the vote to pass, the number of voting
|
||
members voting in the affirmative and negative, and the
|
||
result of the vote.
|
||
|
||
(b) Recording and verifying the attendance and
|
||
membership class of each attendee.
|
||
|
||
(c) Recording the recommendations of subteams.
|
||
|
||
4.4.3.3 The Secretary is also responsible for collecting,
|
||
archiving, and distributing proposals before a formal
|
||
meeting. He or she is also responsible for incorporating
|
||
proposals accepted during a formal meeting into the Standard
|
||
or Charter. Other officers aid the Secretary in these
|
||
duties.
|
||
|
||
4.5 Treasurer
|
||
|
||
4.5.1 The Treasurer is responsible for managing the
|
||
financial business of the FST. He or she is responsible for
|
||
maintaining accurate and current financial records and for
|
||
accepting and dispersing funds for official FST activities.
|
||
|
||
|
||
|
||
81
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
4.5.2 The Treasurer's term of office shall be from the
|
||
conclusion of the formal meeting at which he or she is
|
||
elected to the conclusion of the next formal meeting. The
|
||
election of a Treasurer is held just after the election of
|
||
the Chairperson. Only voting members are eligible to be
|
||
elected Treasurer.
|
||
|
||
|
||
4.6 Referees
|
||
|
||
4.6.1 At the conclusion of a formal meeting there may be
|
||
additional technical work required to prepare a draft
|
||
Standard or Charter. This work shall be performed by the
|
||
officers of the FST, including a group of Referees. They
|
||
should be individuals who have superior knowledge and
|
||
experience in the implementation and use of FORTH.
|
||
|
||
4.6.2 At least three and no more than five Referees shall
|
||
be elected by a majority of the voting members present at
|
||
the concluding general sessions of a formal meeting. This
|
||
takes place after the election of voting members. A
|
||
Referee's term is from election at the end of one formal
|
||
meeting until the end of the next formal meeting. Only
|
||
voting members are eligible to be elected as Referees.
|
||
|
||
4.6.3 The Referees shall adopt methods and rules as they
|
||
deem appropriate to complete their work; they may be
|
||
informal. However, any matter committed to the Referees for
|
||
resolution must achieve near unanimous agreement (not more
|
||
than one no vote). Lacking that, the matter shall be
|
||
omitted from further action pending further consideration at
|
||
the next formal meeting.
|
||
|
||
|
||
5. EXPERIMENTAL PROPOSALS
|
||
|
||
|
||
5.1 General
|
||
|
||
5.1.1 Since FORTH is an extensible language and subject to
|
||
evolution, the Standard may contain a section describing
|
||
experimental proposal to aid in the analysis of and the
|
||
decision for or against future adoption into the Standard.
|
||
After the results of experimentation are known, each
|
||
proposal will be considered, at a future formal meeting, for
|
||
inclusion into the Standard.
|
||
|
||
5.1.2 An experimental proposal may be individual FORTH
|
||
words, sets of related words, or specifications for part of
|
||
the Standard. Experimental proposals may be derived from
|
||
ordinary proposals or other contributions.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
82
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
5.2 Required Information
|
||
|
||
Each experimental proposal must contain the following
|
||
minimum information:
|
||
|
||
5.2.1 A description of the proposal including an overview
|
||
of its functions and its interactions with existing FORTH
|
||
words.
|
||
|
||
5.2.2 A glossary entry of each word in the form and
|
||
notation of the Standard.
|
||
|
||
5.2.3 A statement by the author(s) indicating why the
|
||
proposal meets inclusion into the Standard. Both advantages
|
||
and disadvantages should be discussed.
|
||
|
||
|
||
5.3 Suggested Information
|
||
|
||
It is suggested that each experimental proposal also
|
||
include:
|
||
|
||
5.3.1 A source definition for each word in the proposal.
|
||
High level definitions using Standard words are preferred,
|
||
but new primitive words may be defined in an assembly
|
||
language of one commonly-known processor. Sufficient
|
||
documentation should be provided so that implementation on
|
||
other processors is direct.
|
||
|
||
5.3.2 An example showing usage of the new words.
|
||
|
||
|
||
6. VOTING
|
||
|
||
|
||
6.1 General
|
||
|
||
Only voting members have the right to vote on proposals
|
||
affecting the Standard, a draft Standard, or this Charter.
|
||
|
||
|
||
6.2 Advisory Votes
|
||
|
||
At the discretion of the Chairperson, advisory votes may be
|
||
requested at a formal meeting. At the discretion of the
|
||
Chairperson, all attendees may participate in an advisory
|
||
vote.
|
||
|
||
|
||
6.3 Method
|
||
|
||
Any vote at a formal meeting may be by show of hands or, at
|
||
the discretion of the Chairperson, by an informal secret
|
||
paper ballot or a roll call.
|
||
|
||
|
||
|
||
83
|
||
|
||
|
||
|
||
|
||
|
||
D. CHARTER
|
||
|
||
|
||
6.4 Number
|
||
|
||
A vote to adopt a proposal into the draft Standard or to
|
||
change the Standard, except for the Experimental Proposals
|
||
section of the Standard requires a two-thirds affirmative
|
||
vote of the voting members present at a general session of a
|
||
formal meeting, provided that the number of votes cast are
|
||
at least two thirds of that morning's quorum count. To
|
||
adopt an experimental proposal into the Experimental
|
||
Proposals section of the draft Standard or to change this
|
||
Charter, an affirmative vote of a simple majority is
|
||
required. Accepting any other procedural matter at a formal
|
||
meeting requires only a simple majority affirmative vote.
|
||
|
||
|
||
6.5 Proxies
|
||
|
||
All votes must be cast by the particular voting member
|
||
eligible to vote. No proxy voting is allowed.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
84
|
||
|
||
|
||
|
||
|
||
|
||
E. PROPOSAL/COMMENT FORM
|
||
|
||
|
||
|
||
|
||
APPENDIX E. PROPOSAL/COMMENT FORM
|
||
|
||
|
||
The following pages are the proposal and/or comment submittal
|
||
form. The form includes instructions which should be
|
||
explanatory. Copies of submitted proposals and comments will be
|
||
made available to FORTH Standards Team members and to team
|
||
sponsors.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
85
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
FST Proposal and Comment Submittal Form
|
||
-----------------------------------------------------------------
|
||
FST USER Title: Proposal Number:
|
||
ONLY --> Related Proposals: Disposition:
|
||
=================================================================
|
||
Keyword(s): Category:
|
||
( ) Proposal or ( ) Comment
|
||
FORTH Word(s): Section #(s):
|
||
-----------------------------------------------------------------
|
||
Abstract:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
Proposal and Discussion:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
----------------------------------------------------------------
|
||
Submitted by: Date:
|
||
Page of
|
||
=================================================================
|
||
FORTH Standards Team; PO Box 4545; Mountain View, CA 94040 820801
|
||
|
||
|
||
|
||
86
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Proposal and Comment Submittal Form Instructions
|
||
|
||
Please use the supplied forms for your entire proposal. The
|
||
continuation form is only to be used if absolutely necessary; try
|
||
to get your proposal to fit on the first sheet. If it helps, use
|
||
a reducing copy machine to get more material onto the first
|
||
sheet. If you must use multiple sheets, put the main idea onto
|
||
the first sheet and less important material onto continuation
|
||
sheets. Remember that material on continuation sheets may be
|
||
overlooked.
|
||
|
||
The proposal forms have been produced on a computer system so
|
||
that you may produce your proposals using your own computer
|
||
system. If you print your proposal and form on your computer
|
||
system, all of the information shown on the form(s) MUST be
|
||
printed and in the same location.
|
||
|
||
The following are the instructions for each of the areas of the
|
||
form:
|
||
|
||
1. Please think of the most appropriate keyword or keywords
|
||
describing your proposal.
|
||
|
||
2. Select the best of the following categories of proposals:
|
||
0 Nucleus Layer other than #1 (i.e., + AND )
|
||
1 Memory Operations (i.e., @ CMOVE )
|
||
2 Dictionary (i.e., ' FORGET )
|
||
3 String Operations (i.e., WORD COUNT )
|
||
4 Interpreter Layer other than #2 or #3 (i.e., ABORT . )
|
||
5 Compiler Layer (i.e., : DO )
|
||
6 Device Layer (i.e., BLOCK TYPE )
|
||
7 Experimental (i.e., 32-bit stack entries)
|
||
8 Other Technical (i.e., mono-addressing)
|
||
9 Charter
|
||
|
||
3. Mark whether this is a PROPOSAL or a COMMENT.
|
||
|
||
4. Indicate which FORTH word or words are relevant.
|
||
|
||
5. Indicate which section or sections of the Standard are
|
||
relevant.
|
||
|
||
6. The abstract must be kept short. The title, keywords,
|
||
category, and abstract may be used in a database for
|
||
organization and display on a terminal during a Standards
|
||
Team meeting.
|
||
|
||
7. Detail your proposal and provide supporting discussion.
|
||
|
||
8. Indicate the name of the submitter or the names of the
|
||
submitters.
|
||
|
||
|
||
|
||
|
||
87
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
9. Finally, date the submittal and number each page.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
88
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
FST Proposal and Comment Submittal Continuation Form
|
||
-----------------------------------------------------------------
|
||
FST USE ONLY --> Proposal Number:
|
||
=================================================================
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
Submitted by: Date:
|
||
Page of
|
||
=================================================================
|
||
FORTH Standards Team; PO Box 4545; Mountain View, CA 94040 820801
|
||
|
||
|
||
|
||
89
|
||
|
||
|
||
|