home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / forth / compiler / love / chap18.doc < prev    next >
Text File  |  1993-04-11  |  5KB  |  117 lines

  1.         Multiple Code Field Word Set
  2.  
  3.         These words can be used to create "inteligent" data types.  The
  4. standard Forth word VARIABLE is very simple in its operation, its sole
  5. action is to return the address of its data, what is done with the
  6. address afterwords, is up to the following code.  This action can be
  7. adjusted by adding a DOES> or ;CODE clause to the VARIABLE (or word
  8. with CREATE), but this still offers only a single action to be
  9. performed on the specified data.  This word set allows multiple actions
  10. to be specified.  The particular action to be preformed is specified by
  11. a prefix, used in front of the decalared word.
  12.  
  13.         For example, the word VALUE is proposed for ANSI Forth.  It is
  14. essentially a self-fetching VARIABLE.  A number is stored into a VALUE
  15. by using TO (and perhaps +TO to add into it).  The following is an
  16. implementation of VALUE using the MCFA words:
  17.  
  18.         3 CODEFIELDS
  19.         : VALUE BUILD ( like CREATE ) 0 , ( room for data ) ;
  20.         DO> @ ;       ( fetch action - no prefix used )
  21.         PREFIX TO
  22.         DO> ! ;       ( store action - using prefix TO )
  23.         PREFIX +TO
  24.         DO> +! ;      ( plus-store action - with +TO )
  25.  
  26.         VALUE #trees
  27.         : CUT-DOWN NEGATE +TO #trees ; ( #ToCut -- )
  28.         56 TO #trees
  29.         26 CUT-DOWN   #trees .  ( would print:)
  30.                 30 Ok
  31.  
  32.         This word set is based on the article "Multiple Code Field
  33. Data Types and Prefix Operators" by Klaus Schleisiek (Journal of Forth
  34. Application and Research Volume 1 No. 2 December 1983).  This
  35. implementation has a cleaner syntax.  The RPN assembler must be loaded
  36. in order to compile this word set.
  37.  
  38. Declaring words
  39.  
  40.         First the number of actions (ie. number of code fields or
  41. number of prefixes plus one) is specified with the word CODEFIELDS.
  42. The compile time action is then specified in a colon definition
  43. containing BUILD (works like CREATE).   Following are the
  44. various actions, each begun with DO> or CODE>.  A prefix for the first
  45. action is optional.  This is simply the action taken when no prefix is
  46. used (ie.  first or usual code field).  A prefix must be declared for
  47. each subsequent action.  This is simply specified with PREFIX
  48. <wordname>.  The order is important, the prefix must appear before the
  49. DO> or CODE> clause to which it refers.
  50.  
  51.         When execution begins after a DO> the address on the stack is
  52. whatever data field was defined in the BUILD clause.  This is identical
  53. to the action of DOES> .  Words begun with CODE> are a little more
  54. complex.  The BX register always contains the code field address on
  55. entry to a word.  This is no different here, except that it points to
  56. one of the several declared code fields.  In order to access the data
  57. pointer for example, a constant must be added to it.  This value is
  58. the number of bytes to pass by the rest of the code fields.  This can
  59. be determined from the position of the particular code fields in the
  60. list.  If for example, there are four code fields in total, and CODE>
  61. is used for the second, 6 bytes must be added.
  62.  
  63. Size Penalties
  64.  
  65.         Any reference to or usage of a word created with this word set,
  66. takes two bytes.  The PREFIXes are IMMEDIATE words and force the
  67. compilation of a two byte threaded address just like any other word.
  68. There is a size penalty in that every created word has the specified
  69. number of code field addresses.  If there are many uses of the declared
  70. words, than this is probably not of concern.   In the example above,
  71. every declared VALUE takes 8 bytes in the thread segment (6 for cfas
  72. and two for a data pointer) and two bytes in the data segment.
  73.  
  74. Summary of syntax
  75.         n CODEFIELDS
  76.         : <creatingwordname> BUILD    ....   ;
  77.  
  78.         PREFIX <prefixname>                ( optional first prefix)
  79.         DO>  ... ( actions for first or no prefix) ;
  80.  
  81.         PREFIX <prefixname>
  82.         DO>  ...  ;
  83.  
  84.         PREFIX <prefixname>
  85.         CODE> ... ( rpn assembler code) ... C;
  86.  
  87. Ancillary Words
  88.  
  89.         USE-PREFIX
  90.         Allows a prefix defined to be used with a previous word set, to
  91.         be re-used.   There is one restriction: the number of CFAs in both
  92.         word sets must be the same.   For example:
  93.  
  94.         3 CODEFIELDS
  95.         : DVALUE BUILD ( like CREATE ) 0 , ( room for data ) ;
  96.         DO> D@ ;       ( fetch action - no prefix used )
  97.         USE-PREFIX TO
  98.         DO> D! ;       ( store action - using prefix TO )
  99.         USE-PREFIX +TO
  100.         DO> DUP >R D@ D+ R> D! ;      ( plus-store action - with +TO )
  101.  
  102. Examples
  103.  
  104. INTEGER and DOUBLE
  105.         These are formed using multiple cfa words.  Both are sometimes
  106. called: self-fetching variables.  DOUBLE is simply the 32 bit counterpart
  107. of INTEGER (16 bits).   To fetch the value from an INTEGER, simply
  108. name it (like a CONSTANT).  To store a value use: ->
  109.         Example:
  110.                 INTEGER #of-flower-pots
  111.                 74 -> #of-flower-pots
  112.                 : PRINT-IT  ." Number of pots:" #of-flower-pots . ;
  113.  
  114.         The word:  +>  is like -> but adds into the integer, analogous to +! ,
  115. used with a VARIABLE.  The double precision counterparts of -> and +> are
  116. D-> and D+> .   INTEGER is like the ANSI proposed word VALUE, except that
  117. -> is used instead of TO .