home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / forth / compiler / love / chap17.doc < prev    next >
Text File  |  1993-04-11  |  7KB  |  168 lines
  1.                Local Variables in L.O.V.E. Forth
  2.                =================================
  3.  
  4. Stack Manipulation
  5. ------------------
  6.  
  7.     Forth source code has been criticized by many as unreadable. This 
  8. is due to the traditional use of stack manipulation operators (such as 
  9. swap, dup, rot, pick, roll etc... ) rather than the reverse polish syntax. 
  10. Incorrect manipulation of the parameter stack in Forth is such a frequent 
  11. source of logical bugs that experienced Forth programmers habitually insert 
  12. 'stack diagrams' beside their phrases to document the net effect on the 
  13. stack. The problem of ordering data items on the stack is compounded by the 
  14. use of double and quad length items to represent pointers of different 
  15. sizes, large valued integers and floating point numbers. In an attempt to 
  16. remedy this, many versions of local variables and named parameters have 
  17. been implemented by Forth programmers. The implementation for L.O.V.E. 
  18. Forth has a syntax modelled after that used in a Forth-83 system for the 
  19. Apple Macintosh called MACH-2 by Palo Alto Shipping Company.
  20.  
  21.  
  22.  
  23. Benefits
  24. --------
  25.  
  26.     Local variables and named input parameters are an addition to the 
  27. L.O.V.E. Forth compiler that improves the readability of source code and 
  28. allows the programmer to spend less time thinking about the order and sizes 
  29. of data items on Forth's parameter stack. An additional and significant 
  30. benefit is increased execution speed and decreased object code size. Local 
  31. variables and named input parameters insulate the implementation of a 
  32. definition from changes to the order and data types of the input 
  33. parameters, are used at the programmers discretion and are entirely 
  34. optional.  This implementation of local variables allows the programmer to 
  35. write completely re-entrant code and recursive definitions with ease.
  36.  
  37.  
  38. Usage
  39. -----
  40.  
  41.  
  42.     The syntax used replaces the traditional stack diagram after the 
  43. name of the new definition.
  44.  
  45.     Local variables and named input parameters have a structure 
  46. following this general form:
  47.  
  48.  
  49. : aname  { [type] n1 [type] n2 ... [type] n? | [type] L1  ... [type] L? -- comment }
  50.         ...  ;
  51.  
  52. where:
  53.  
  54. '{'       is an immediate word that precedes a locxal variable specification
  55.           list and parses this information up to the first '}' and must be used
  56.           immediately after the name of the new definition.
  57.  
  58.  
  59. [type]    is a built in type specifier that tells the parser how to compile
  60.           object code for the local variable name following it in the local
  61.           variable specification.
  62.           Available types are:
  63.  
  64.                 word:   -- a two byte (word length) integer
  65.                 long:   -- a four byte (long word length) integer
  66.                 quad:   -- an eight byte (quad word length) integer
  67.                 float:  -- a four byte (single precision) floating point value
  68.                            in IEEE single precision format
  69.                 double: -- an eight byte (double precision) floating point
  70.                            value in IEEE double precision format
  71.                 ext:    -- a ten byte (extended precision) floating point
  72.                            value in IEEE extended precision format
  73.                 fbcd:   -- a ten byte (binary coded decimal) floating point
  74.                            value in 80x87 BCD format
  75.  
  76.         ** NOTE : If a local variable name appears without a type specifier
  77.                   the parser assumes that it is a 'word:' type. This allows
  78.                   the programmer to write simple definitions using mostly word
  79.                   length items without always specifying the 'word:' type.
  80.  
  81.  
  82. n1 n2 n3 ...        are named input parameters from the stack where n1 is
  83.                     deepest in the stack and n? is on the top of the
  84.                     parameter stack.
  85.  
  86. | (bar)             is a separator character that terminates the input variable
  87.                     list and signals that a local variable list will begin.
  88.  
  89. L1 L2 L3 ...        is the list of local variable names used in this
  90.                     definition.
  91.  
  92. --                  specifies that a comment begins, a comment string follows,
  93.                     usually used to document what the definition leaves on the
  94.                     stack. May not contain '}'  .
  95.  
  96.  
  97.  
  98. Notes:
  99.  
  100. (1)    Named parameters, temporary local variables and the comment are all
  101.        optional. A definition with no input parameters can have local
  102.        variables for temporary results.
  103.  
  104. (2)    In the V1.24 implementation a local variable stack frame can contain up
  105.        to 128 bytes of named input parameters and temporary local variables
  106.        (one local frame per definition).
  107.  
  108. (3)    Local names can be any space delimited string up to 31 characters
  109.        long but must not be named '|' (bar) or '--' (comment) or '}' (left
  110.        brace) or given a name that is identical to a type specifier .
  111.  
  112.  
  113. Examples
  114. --------
  115.  
  116.  
  117.           : <a_word>   { arg1 arg2 arg3  | temp  -- result }
  118.                ...............
  119.                ...............   ;
  120.  
  121.  
  122.  
  123. The named arguments 'arg1', 'arg2' and 'arg3' are initialized values on the
  124. parameter stack with 'arg3' on the top and 'arg1' deepest on the stack. The
  125. local variable 'temp' is an uninitialized temporary value.
  126.  
  127.           : <b_word>   { word: arg1   long: arg2   | ext: temp  -- result }
  128.                ...............
  129.                ...............   ;
  130.  
  131.  
  132.  
  133. The named arguments 'arg1', 'arg2' are initialized values on the
  134. parameter stack with long word length 'arg2' on the top and word length 'arg1'
  135. deepest on the stack. The local variable 'temp' is an uninitialized extended
  136. precision floating point temporary value.
  137.  
  138.  
  139.  
  140.  
  141. Operations with Local Variables
  142. -------------------------------
  143.  
  144. There are 4 basic operations with local variables and the possibility of
  145. adding more operations in the future.
  146. These operations are:
  147.  
  148.        local_name    -- the default action of a local variable is to fetch
  149.                             the contents of the local variable to the top
  150.                             of the stack.
  151.  
  152.        -> local_name -- stores the top of stack into the location specified by
  153.                         local_name in the format specified by the type of
  154.                         local_name.
  155.  
  156.        +> local_name -- adds the top of stack to the contents of the location
  157.                         specified by local_name in the format specified by the
  158.                         type of local_name.
  159.  
  160.        & local_name  -- returns the segment and offset of the contents of
  161.                             local_name.
  162.  
  163.  
  164.  
  165.  
  166. All operations with local variables are immediate words that determine at
  167. compile time what type of data will be operated upon and then compile the
  168. correct object code.