misc/kforth: Add forth standard 83
This commit is contained in:
		
							parent
							
								
									7fc402e30a
								
							
						
					
					
						commit
						825dbf927e
					
				
										
											
												File diff suppressed because it is too large
												Load Diff
											
										
									
								
							| 
						 | 
				
			
			@ -0,0 +1,265 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
                                  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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,93 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,132 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,264 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
										
											
												File diff suppressed because it is too large
												Load Diff
											
										
									
								
							| 
						 | 
				
			
			@ -0,0 +1,198 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,139 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,132 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,198 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,91 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
          
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,91 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
          
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,67 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,596 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,67 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,66 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,132 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,199 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,198 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,594 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,728 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,331 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,69 @@
 | 
			
		|||
( -*- forth -*- )
 | 
			
		||||
 | 
			
		||||
checking ================= REQUIRED WORD SET ====================
 | 
			
		||||
 | 
			
		||||
checking Nucleus layer
 | 
			
		||||
checks: ! *
 | 
			
		||||
 | 
			
		||||
checks:  !  *  */  */MOD  +  +!  -  /  /MOD  0<  0=  0>  1+  1-  2+
 | 
			
		||||
checks:  2-  2/  <  =  >  >R  ?DUP  @  ABS  AND  C!  C@  CMOVE
 | 
			
		||||
checks:  CMOVE>  COUNT  D+  D<  DEPTH  DNEGATE  DROP  DUP  EXECUTE
 | 
			
		||||
checks:  EXIT  FILL  I  J  MAX  MIN  MOD  NEGATE  NOT  OR  OVER  PICK
 | 
			
		||||
checks:  R>  R@  ROLL  ROT  SWAP  U<  UM*  UM/MOD  XOR
 | 
			
		||||
 | 
			
		||||
checking Device layer
 | 
			
		||||
 | 
			
		||||
checks:  BLOCK  BUFFER  CR  EMIT  EXPECT  FLUSH  KEY  SAVE-BUFFERS
 | 
			
		||||
checks:  SPACE  SPACES  TYPE  UPDATE
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking Interpreter layer
 | 
			
		||||
 | 
			
		||||
checks:  #  #>  #S  #TIB  '  (  -TRAILING  .  .(  <#  >BODY  >IN
 | 
			
		||||
checks:  ABORT  BASE  BLK  CONVERT  DECIMAL  DEFINITIONS  FIND
 | 
			
		||||
checks:  FORGET  FORTH  FORTH-83  HERE  HOLD  LOAD  PAD  QUIT  SIGN
 | 
			
		||||
checks:  SPAN  TIB  U.  WORD
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking  Compiler layer
 | 
			
		||||
 | 
			
		||||
checks:   +LOOP  ,  ."  :  ;  ABORT"  ALLOT  BEGIN  COMPILE  CONSTANT
 | 
			
		||||
checks:   CREATE  DO  DOES>  ELSE  IF  IMMEDIATE  LEAVE  LITERAL  LOOP
 | 
			
		||||
checks:   REPEAT  STATE  THEN  UNTIL  VARIABLE  VOCABULARY  WHILE  [
 | 
			
		||||
checks:   [']  [COMPILE]  ]
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
                                         44
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,17 @@
 | 
			
		|||
checking ============== The Double Number Extension Word Set Layers
 | 
			
		||||
 | 
			
		||||
checking Nucleus layer
 | 
			
		||||
 | 
			
		||||
checks:  2!  2@  2DROP  2DUP  2OVER  2ROT  2SWAP  D+  D-  D0=  D2/
 | 
			
		||||
checks:  D<  D=  DABS  DMAX  DMIN  DNEGATE  DU<
 | 
			
		||||
 | 
			
		||||
checking Interpreter layer
 | 
			
		||||
 | 
			
		||||
checks:  D.  D.R
 | 
			
		||||
 | 
			
		||||
checking Compiler layer
 | 
			
		||||
 | 
			
		||||
checks:  2CONSTANT  2VARIABLE
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,13 @@
 | 
			
		|||
checking =============== The Assembler Extension Word Set Layers
 | 
			
		||||
 | 
			
		||||
checking Interpreter layer
 | 
			
		||||
 | 
			
		||||
checks:  ASSEMBLER
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking  Compiler layer
 | 
			
		||||
 | 
			
		||||
checks:  ;CODE  CODE  END-CODE
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,20 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
checking ================== The System Extension Word Set Layers
 | 
			
		||||
 | 
			
		||||
checking Nucleus layer
 | 
			
		||||
 | 
			
		||||
checks:  BRANCH  ?BRANCH
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking Interpreter layer
 | 
			
		||||
 | 
			
		||||
checks:  CONTEXT  CURRENT
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking Compiler layer
 | 
			
		||||
 | 
			
		||||
checks:  <MARK  <RESOLVE  >MARK  >RESOLVE
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,10 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking =================  CONTROLLED REFERENCE WORDS
 | 
			
		||||
 | 
			
		||||
checks:  -->  .R  2*  BL  BLANK  C,  DUMP  EDITOR  EMPTY-BUFFERS
 | 
			
		||||
checks:  END  ERASE  HEX  INTERPRET  K  LIST OCTAL  OFFSET QUERY
 | 
			
		||||
checks:  RECURSE  SCR  SP@  THRU  U.R
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,19 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
checking  UNCONTROLLED REFERENCE WORDS
 | 
			
		||||
(  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.            )
 | 
			
		||||
 | 
			
		||||
checks:  !BITS  **  +BLOCK  -'  -MATCH  -TEXT  /LOOP  1+!  1-!  ;:  ;S
 | 
			
		||||
checks:  <> <BUILDS  <CMOVE  ><  >MOVE<  @BITS  AGAIN  ASCII  ASHIFT  B/BUF
 | 
			
		||||
checks:  BELL  CHAIN  CONTINUED  CUR  DBLOCK  DPL  FLD  H.  I'  
 | 
			
		||||
checks:  IFEND  IFTRUE  INDEX  LAST  LINE  LINELOAD  LOADS  MAP0
 | 
			
		||||
checks:  MASK  MOVE  MS  NAND  NOR  NUMBER  O.  OTHERWISE  PAGE  READ-MAP
 | 
			
		||||
checks:  REMEMBER  REWIND  ROTATE  S0  SET  SHIFT  TEXT  USER  WORDS
 | 
			
		||||
checks:  \LOOP
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,11 @@
 | 
			
		|||
 | 
			
		||||
checking =====================  EXPERIMENTAL PROPOSALS
 | 
			
		||||
 | 
			
		||||
checking SEARCH ORDER SPECIFICATION AND CONTROL
 | 
			
		||||
 | 
			
		||||
checks:  ONLY  FORTH  ALSO  ORDER  WORDS   FORGET  DEFINITIONS SEAL
 | 
			
		||||
 | 
			
		||||
checking DEFINITION FIELD ADDRESS CONVERSION OPERATORS
 | 
			
		||||
 | 
			
		||||
checks:  >BODY  >NAME  >LINK  BODY>  NAME>  LINK> N>LINK L>NAME
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,33 @@
 | 
			
		|||
( -*- forth -*- )
 | 
			
		||||
 | 
			
		||||
: checking ( [text<:>] -- )
 | 
			
		||||
    [char] : parse ." /////// " type cr
 | 
			
		||||
;
 | 
			
		||||
 | 
			
		||||
: checks: ( [text< >].. -- )
 | 
			
		||||
	8 spaces
 | 
			
		||||
	begin
 | 
			
		||||
		bl word 
 | 
			
		||||
		dup dup if c@ then 
 | 
			
		||||
	while
 | 
			
		||||
		dup count type space
 | 
			
		||||
		dup find if 2drop
 | 
			
		||||
		else cr ." missing " count type cr 8 spaces
 | 
			
		||||
		then
 | 
			
		||||
	repeat
 | 
			
		||||
        cr
 | 
			
		||||
	drop
 | 
			
		||||
;
 | 
			
		||||
 | 
			
		||||
include fst83_12.fs
 | 
			
		||||
include fst83_13.fs
 | 
			
		||||
include fst83_14.fs
 | 
			
		||||
include fst83_15.fs
 | 
			
		||||
include fst83_16.fs
 | 
			
		||||
include fst83_b.fs
 | 
			
		||||
include fst83_c.fs
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,462 @@
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
          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
 | 
			
		||||
 | 
			
		||||
		Loading…
	
		Reference in New Issue