umouse

umouse.git
git clone git://git.lenczewski.org/umouse.git
Log | Files | Refs | Submodules | README

DPANSA3.HTM (44433B)


      1 <HTML><HEAD>
      2 <TITLE>DPANS94</TITLE>
      3 <link disabled rel="stylesheet" href="mpexc6.css">
      4 <style>@import url(mpexc6.css);</style>
      5 </head>
      6 
      7 <BODY>
      8 <table width=100%>
      9 <tr>
     10 <td align=left>
     11 <a href=dpansa2.htm><img src=left.gif
     12  width=26 height=26 align=ALIGN border=0></a>
     13 <a href=dpansa4.htm><img src=right.gif
     14  width=26 height=26 align=ALIGN border=0></a>
     15 </td>
     16 <td align=right>
     17 <a href=dpans.htm#toc><img src=up.gif 
     18  width=26 height=26 align=ALIGN border=0></a>
     19 <a name=A.3>Table of Contents</a>
     20 </td>
     21 </tr>
     22 </table>
     23 <p>
     24 <hr size=4>
     25 
     26 <H1>A.3 Usage requirements</H1>
     27 
     28 Forth systems are unusually simple to develop, in comparison with
     29 compilers for more conventional languages such as C.  In addition to
     30 Forth systems supported by vendors, public-domain implementations and
     31 implementation guides have been widely available for nearly twenty
     32 years, and a large number of individuals have developed their own Forth
     33 systems.  As a result, a variety of implementation approaches have
     34 developed, each optimized for a particular platform or target market.
     35 
     36 <P>
     37 
     38 The X3J14 Technical Committee has endeavored to accommodate this
     39 diversity by constraining implementors as little as possible, consistent
     40 with a goal of defining a standard interface between an underlying Forth
     41 System and an application program being developed on it.
     42 
     43 <P>
     44 
     45 Similarly, we will not undertake in this section to tell you how to
     46 implement a Forth System, but rather will provide some guidance as to
     47 what the minimum requirements are for systems that can properly claim
     48 compliance with this Standard.
     49 
     50 <P>
     51 
     52 <hr>
     53 <a name=A.3.1>
     54 <H2>A.3.1 Data-types</H2>
     55 </a>
     56 
     57 Most computers deal with arbitrary bit patterns.  There is no way to
     58 determine by inspection whether a cell contains an address or an
     59 unsigned integer.  The only meaning a datum possesses is the meaning
     60 assigned by an application.
     61 
     62 <P>
     63 
     64 When data are operated upon, the meaning of the result depends on the
     65 meaning assigned to the input values.  Some combinations of input values
     66 produce meaningless results: for instance, what meaning can be assigned
     67 to the arithmetic sum of the ASCII representation of the character
     68 <B>A</B> and a 
     69 <a href=dpans6.htm#6.2.2298>TRUE</a> 
     70 flag? The answer may be <B>no meaning</B>; or
     71 alternatively, that operation might be the first step in producing a
     72 checksum.  Context is the determiner.
     73 
     74 <P>
     75 
     76 The discipline of circumscribing meaning which a program may assign to
     77 various combinations of bit patterns is sometimes called data typing.
     78 Many computer languages impose explicit data typing and have compilers
     79 that prevent ill-defined operations.
     80 
     81 <P>
     82 
     83 Forth rarely explicitly imposes data-type restrictions.  Still, data
     84 types implicitly do exist, and discipline is required, particularly if
     85 portability of programs is a goal.  In Forth, it is incumbent upon the
     86 programmer (rather than the compiler) to determine that data are
     87 accurately typed.
     88 
     89 <P>
     90 
     91 This section attempts to offer guidance regarding de facto data typing
     92 in Forth.
     93 
     94 <P>
     95 
     96 <hr>
     97 <a name=A.3.1.2>
     98 <H3>A.3.1.2 Character types</H3>
     99 </a>
    100 
    101 The correct identification and proper manipulation of the character data
    102 type is beyond the purview of Forth's enforcement of data type by means
    103 of stack depth.  Characters do not necessarily occupy the entire width
    104 of their single stack entry with meaningful data.  While the distinction
    105 between signed and unsigned character is entirely absent from the formal
    106 specification of Forth, the tendency in practice is to treat characters
    107 as short positive integers when mathematical operations come into play.
    108 
    109 <P>
    110 
    111 <dl>
    112 a) Standard Character Set
    113 
    114 <P>
    115 
    116 <dl>
    117 1) The storage unit for the character data type 
    118 (<a href=dpans6.htm#6.1.0870>C@</a>, 
    119 <a href=dpans6.htm#6.1.0850>C!</a>, 
    120 <a href=dpans6.htm#6.1.1540>FILL</a>, etc.) must be
    121 able to contain unsigned numbers from 0 through 255.
    122 
    123 <P>
    124 
    125 2) An implementation is not required to restrict character storage to
    126 that range, but a Standard Program without environmental dependencies
    127 cannot assume the ability to store numbers outside that range in a
    128 <B>char</B> location.
    129 
    130 <P>
    131 
    132 3) The allowed number representations are two's-complement,
    133 one's-complement, and signed-magnitude.  Note that all of these number
    134 systems agree on the representation of positive numbers.
    135 
    136 <P>
    137 
    138 4) Since a <B>char</B> can store small positive numbers and since the
    139 character data type is a sub-range of the unsigned integer data type, C!
    140 must store the n least-significant bits of a cell (8 <= n <= bits/cell).
    141 Given the enumeration of allowed number representations and their known
    142 encodings, 
    143 <B><code>TRUE xx C! xx C@</code></B> must leave a stack item with some
    144 number of bits set, which will thus will be accepted as non-zero by 
    145 <a href=dpans6.htm#6.1.1700>IF</a>.
    146 
    147 <P>
    148 
    149 5) For the purposes of input 
    150 (<a href=dpans6.htm#6.1.1750>KEY</a>, 
    151 <a href=dpans6.htm#6.1.0695>ACCEPT</a>, 
    152 etc.) and output 
    153 (<a href=dpans6.htm#6.1.1320>EMIT</a>, 
    154 <a href=dpans6.htm#6.1.2310>TYPE</a>,
    155 etc.), the encoding between numbers and human-readable symbols is
    156 ISO646/IRV (ASCII) within the range from 32 to 126 (space to ~).  EBCDIC
    157 is out (most <B>EBCDIC</B> computer systems support ASCII too).  Outside
    158 that range, it is up to the implementation.  The obvious implementation
    159 choice is to use ASCII control characters for the range from 0 to 31, at
    160 least for the <B>displayable</B> characters in that range (TAB, RETURN,
    161 LINEFEED, FORMFEED).  However, this is not as clear-cut as it may seem,
    162 because of the variation between operating systems on the treatment of
    163 those characters.  For example, some systems TAB to 4 character
    164 boundaries, others to 8 character boundaries, and others to preset tab
    165 stops.  Some systems perform an automatic linefeed after a carriage
    166 return, others perform an automatic carriage return after a linefeed,
    167 and others do neither.
    168 
    169 <P>
    170 
    171 The codes from 128 to 255 may eventually be standardized, either
    172 formally or informally, for use as international characters, such as the
    173 letters with diacritical marks found in many European languages.  One
    174 such encoding is the 8-bit ISO Latin-1 character set.  The computer
    175 marketplace at large will eventually decide which encoding set of those
    176 characters prevails.  For Forth implementations running under an
    177 operating system (the majority of those running on standard platforms
    178 these days), most Forth implementors will probably choose to do whatever
    179 the system does, without performing any remapping within the domain of
    180 the Forth system itself.
    181 
    182 <P>
    183 
    184 6) A Standard Program can depend on the ability to receive any character
    185 in the range 32 ...  126 through KEY, and similarly to display the same
    186 set of characters with EMIT.  If a program must be able to receive or
    187 display any particular character outside that range, it can declare an
    188 environmental dependency on the ability to receive or display that
    189 character.
    190 
    191 <P>
    192 
    193 7) A Standard Program cannot use control characters in definition names.
    194 However, a Standard System is not required to enforce this prohibition.
    195 Thus, existing systems that currently allow control characters in words
    196 names from 
    197 <a href=dpans7.htm#7.6.1.0790>BLOCK</a> 
    198 source may continue to allow them, and programs running
    199 on those systems will continue to work.  In text file source, the
    200 parsing action with space as a delimiter (e.g., 
    201 <a href=dpans6.htm#6.1.0770>BL</a> 
    202 <a href=dpans6.htm#6.1.2450>WORD</a>) treats control
    203 characters the same as spaces.  This effectively implies that you cannot
    204 use control characters in definition names from text-file source, since
    205 the text interpreter will treat the control characters as delimiters.
    206 Note that this <B>control-character folding</B> applies only when space
    207 is the delimiter, thus the phrase 
    208 <code><B>CHAR ) WORD</B></code> may collect a
    209 string containing control characters.
    210 </dl>
    211 <P>
    212 
    213 b) Storage and retrieval
    214 <P>
    215 
    216 <dl>
    217 Characters are transferred from the data stack to memory by C! and from
    218 memory to the data stack by C@.  A number of lower-significance bits
    219 equivalent to the implementation-dependent width of a character are
    220 transferred from a popped data stack entry to an address by the action
    221 of C! without affecting any bits which may comprise the
    222 higher-significance portion of the cell at the destination address;
    223 however, the action of C@ clears all higher-significance bits of the
    224 data stack entry which it pushes that are beyond the
    225 implementation-dependent width of a character (which may include
    226 implementation-defined display information in the higher-significance
    227 bits).  The programmer should keep in mind that operating upon arbitrary
    228 stack entries with words intended for the character data type may result
    229 in truncation of such data.
    230 </dl>
    231 <P>
    232 
    233 c) Manipulation on the stack
    234 <P>
    235 
    236 <dl>
    237 In addition to C@ and C!, characters are moved to, from and upon the
    238 data stack by the following words:
    239 
    240 <P>
    241 
    242 <code>
    243 <a href=dpans6.htm#6.1.0580>&gt;R</a>  
    244 <a href=dpans6.htm#6.1.0630>?DUP</a>  
    245 <a href=dpans6.htm#6.1.1260>DROP</a>  
    246 <a href=dpans6.htm#6.1.1290>DUP</a>  
    247 <a href=dpans6.htm#6.1.1990>OVER</a>  
    248 <a href=dpans6.htm#6.2.2030>PICK</a>  
    249 <a href=dpans6.htm#6.1.2060>R&gt;</a>  
    250 <a href=dpans6.htm#6.1.2070>R@</a>  
    251 <a href=dpans6.htm#6.2.2150>ROLL</a>  
    252 <a href=dpans6.htm#6.1.2160>ROT</a>  
    253 <a href=dpans6.htm#6.1.2260>SWAP</a>
    254 </code>
    255 </dl>
    256 <P>
    257 
    258 d) Additional operations
    259 <P>
    260 
    261 <dl>
    262 The following mathematical operators are valid for character data:
    263 
    264 <P>
    265 
    266 <code>
    267 <a href=dpans6.htm#6.1.0120>+</a>  
    268 <a href=dpans6.htm#6.1.0160>-</a>  
    269 <a href=dpans6.htm#6.1.0090>*</a>  
    270 <a href=dpans6.htm#6.1.0230>/</a>  
    271 <a href=dpans6.htm#6.1.0240>/MOD</a>  
    272 <a href=dpans6.htm#6.1.1890>MOD</a>
    273 </code>
    274 <P>
    275 
    276 The following comparison and bitwise operators may be valid for
    277 characters, keeping in mind that display information cached in the most
    278 significant bits of characters in an implementation-defined fashion may
    279 have to be masked or otherwise dealt with:
    280 
    281 <P>
    282 
    283 <code>
    284 <a href=dpans6.htm#6.1.0720>AND</a>  
    285 <a href=dpans6.htm#6.1.1980>OR</a>  
    286 <a href=dpans6.htm#6.1.0540>&gt;</a>  
    287 <a href=dpans6.htm#6.1.0480>&lt;</a>  
    288 <a href=dpans6.htm#6.2.2350>U&gt;</a>  
    289 <a href=dpans6.htm#6.1.2340>U&lt;</a>  
    290 <a href=dpans6.htm#6.1.0530>=</a>  
    291 <a href=dpans6.htm#6.2.0500>&lt;&gt;</a>  
    292 <a href=dpans6.htm#6.1.0270>0=</a>  
    293 <a href=dpans6.htm#6.2.0260>0&lt;&gt;</a>  
    294 <a href=dpans6.htm#6.1.1870>MAX</a>  
    295 <a href=dpans6.htm#6.1.1880>MIN</a> 
    296 <a href=dpans6.htm#6.1.1805>LSHIFT</a> 
    297 <a href=dpans6.htm#6.1.2162>RSHIFT</a>
    298 </code>
    299 
    300 </dl>
    301 </dl>
    302 <P>
    303 
    304 
    305 <hr>
    306 <a name=A.3.1.3>
    307 <h3>A.3.1.3   Single-cell types</h3>
    308 </a>
    309 <P>
    310 
    311 A single-cell stack entry viewed without regard to typing is the
    312 fundamental data type of Forth.  All other data types are actually
    313 represented by one or more single-cell stack entries.
    314 
    315 <P>
    316 
    317 <dl>
    318 a) Storage and retrieval
    319 <P>
    320 
    321 
    322 <dl>
    323 Single-cell data are transferred from the stack to memory by 
    324 <a href=dpans6.htm#6.1.0010>!</a>; from
    325 memory to the stack by 
    326 <a href=dpans6.htm#6.1.0650>@</a>.  
    327 All bits are transferred in both directions
    328 and no type checking of any sort is performed, nor does the Standard
    329 System check that a memory address used by ! or @ is properly aligned or
    330 properly sized to hold the datum thus transferred.
    331 </dl>
    332 <P>
    333 
    334 b) Manipulation on the stack
    335 <P>
    336 
    337 <dl>
    338 Here is a selection of the most important words which move single-cell
    339 data to, from and upon the data stack:
    340 
    341 <P>
    342 
    343 <code>
    344 !  
    345 @  
    346 <a href=dpans6.htm#6.1.0580>&gt;R</a>  
    347 <a href=dpans6.htm#6.1.0630>?DUP</a>  
    348 <a href=dpans6.htm#6.1.1260>DROP</a>  
    349 <a href=dpans6.htm#6.1.1290>DUP</a>  
    350 <a href=dpans6.htm#6.1.1990>OVER</a>  
    351 <a href=dpans6.htm#6.2.2030>PICK</a>  
    352 <a href=dpans6.htm#6.1.2060>R&gt;</a>  
    353 <a href=dpans6.htm#6.1.2070>R@</a>  
    354 <a href=dpans6.htm#6.2.2150>ROLL</a>  
    355 <a href=dpans6.htm#6.1.2160>ROT</a>  
    356 <a href=dpans6.htm#6.1.2260>SWAP</a>
    357 </code>
    358 </dl>
    359 <P>
    360 
    361 c) Comparison operators
    362 <P>
    363 
    364 <dl>
    365 The following comparison operators are universally valid for one or more
    366 single cells:
    367 
    368 <P>
    369 
    370 <code>
    371 <a href=dpans6.htm#6.1.0530>=</a>  
    372 <a href=dpans6.htm#6.2.0500>&lt;&gt;</a>  
    373 <a href=dpans6.htm#6.1.0270>0=</a>  
    374 <a href=dpans6.htm#6.2.0260>0&lt;&gt;</a>
    375 </code>
    376 <P>
    377 </dl>
    378 </dl>
    379 
    380 <hr>
    381 <a name=A.3.1.3.1>
    382 <H4>A.3.1.3.1 Flags</H4>
    383 </a>
    384 
    385 A 
    386 <a href=dpans6.htm#6.2.1485>FALSE</a> 
    387 flag is a single-cell datum with all bits unset, and a 
    388 <a href=dpans6.htm#6.2.2298>TRUE</a> 
    389 flag
    390 is a single-cell datum with all bits set.  While Forth words which test
    391 flags accept any non-null bit pattern as true, there exists the concept
    392 of the well-formed flag.  If an operation whose result is to be used as
    393 a flag may produce any bit-mask other than TRUE or FALSE, the
    394 recommended discipline is to convert the result to a well-formed flag by
    395 means of the Forth word 
    396 <a href=dpans6.htm#6.2.0260>0&lt;&gt;</a> 
    397 so that the result of any subsequent logical
    398 operations on the flag will be predictable.
    399 
    400 <P>
    401 
    402 In addition to the words which move, fetch and store single-cell items,
    403 the following words are valid for operations on one or more flag data
    404 residing on the data stack:
    405 
    406 <P>
    407 
    408 <code>
    409 <a href=dpans6.htm#6.1.0720>AND</a>  
    410 <a href=dpans6.htm#6.1.1980>OR</a>  
    411 <a href=dpans6.htm#6.1.2490>XOR</a>  
    412 <a href=dpans6.htm#6.1.1720>INVERT</a>
    413 </code>
    414 <P>
    415 
    416 <hr>
    417 <a name=A.3.1.3.2>
    418 <h4>A.3.1.3.2 Integers</h4>
    419 </a>
    420 <p>
    421 
    422 Given the same number of bits, unsigned integers usually represent twice
    423 the number of absolute values representable by signed integers.
    424 
    425 <P>
    426 
    427 A single-cell datum may be treated by a Standard Program as an unsigned
    428 integer.  Moving and storing such data is performed as for any
    429 single-cell data.  In addition, the following mathematical and
    430 comparison operators are valid for single-cell unsigned integers:
    431 
    432 <P>
    433 
    434 <code>
    435 <a href=dpans6.htm#6.1.2360>UM*</a>  
    436 <a href=dpans6.htm#6.1.2370>UM/MOD</a>  
    437 <a href=dpans6.htm#6.1.0120>+</a>  
    438 <a href=dpans6.htm#6.1.0130>+!</a>  
    439 <a href=dpans6.htm#6.1.0160>-</a>  
    440 <a href=dpans6.htm#6.1.0290>1+</a>  
    441 <a href=dpans6.htm#6.1.0300>1-</a>  
    442 <a href=dpans6.htm#6.1.0090>*</a>  
    443 <a href=dpans6.htm#6.1.2340>U&lt;</a>  
    444 <a href=dpans6.htm#6.2.2350>U&gt;</a>
    445 </code>
    446 <P>
    447 
    448 
    449 <hr>
    450 <a name=A.3.1.3.3>
    451 <H4>A.3.1.3.3 Addresses</H4>
    452 </a>
    453 
    454 An address is uniquely represented as a single cell unsigned number and can be
    455 treated as such when being moved to, from, or upon the stack.  Conversely,
    456 each unsigned number represents a unique address (which is not necessarily an
    457 address of accessible memory).  This one-to-one relationship between addresses
    458 and unsigned numbers forces an equivalence between address arithmetic and the
    459 corresponding operations on unsigned numbers.
    460 
    461 <P>
    462 
    463 Several operators are provided specifically for address arithmetic:
    464 <P>
    465 
    466 <code>
    467 <a href=dpans6.htm#6.1.0897>CHAR+</a>  
    468 <a href=dpans6.htm#6.1.0898>CHARS</a>  
    469 <a href=dpans6.htm#6.1.0880>CELL+</a>  
    470 <a href=dpans6.htm#6.1.0890>CELLS</a>
    471 </code>
    472 <P>
    473 
    474 and, if the floating-point word set is present:
    475 <P>
    476 
    477 <code>
    478 <a href=dpans12.htm#12.6.1.1555>FLOAT+</a>  
    479 <a href=dpans12.htm#12.6.1.1556>FLOATS</a>  
    480 <a href=dpans12.htm#12.6.2.2207>SFLOAT+</a>  
    481 <a href=dpans12.htm#12.6.2.2208>SFLOATS</a>  
    482 <a href=dpans12.htm#12.6.2.1208>DFLOAT+</a>  
    483 <a href=dpans12.htm#12.6.2.1209>DFLOATS</a>
    484 </code>
    485 <P>
    486 
    487 A Standard Program may never assume a particular correspondence between
    488 a Forth address and the physical address to which it is mapped.
    489 
    490 <P>
    491 
    492 
    493 <hr>
    494 <a name=A.3.1.3.4>
    495 <H4>A.3.1.3.4 Counted strings</H4>
    496 </a>
    497 
    498 The trend in ANS Forth is to move toward the consistent use of the
    499 <B>c-addr u</B> representation of strings on the stack.  The use of the
    500 alternate <B>address of counted string</B> stack representation is
    501 discouraged.  The traditional Forth words 
    502 <a href=dpans6.htm#6.1.2450>WORD</a> and 
    503 <a href=dpans6.htm#6.1.1550>FIND</a> 
    504 continue to use
    505 the <B>address of counted string</B> representation for historical
    506 reasons.  The new word 
    507 <a href=dpans6.htm#6.2.0855>C"</a> 
    508 , added as a porting aid for existing
    509 programs, also uses the counted string representation.
    510 
    511 <P>
    512 
    513 Counted strings remain useful as a way to store strings in memory.  This
    514 use is not discouraged, but when references to such strings appear on
    515 the stack, it is preferable to use the <B>c-addr u</B> representation.
    516 
    517 <P>
    518 
    519 
    520 <hr>
    521 <a name=A.3.1.3.5>
    522 <H4>A.3.1.3.5 Execution tokens</H4>
    523 </a>
    524 
    525 The association between an execution token and a definition is static.
    526 Once made, it does not change with changes in the search order or
    527 anything else.  However it may not be unique, e.g., the phrases
    528 
    529 <PRE>
    530 	<b>' 1+</b> 
    531    and
    532 
    533 	<b>' CHAR+</b>
    534 </PRE>
    535 might return the same value.
    536 
    537 <P>
    538 
    539 
    540 <hr>
    541 <a name=A.3.1.4>
    542 <H3>A.3.1.4 Cell-pair types</H3>
    543 </a>
    544 
    545 <dl>
    546 a) Storage and retrieval
    547 <P>
    548 
    549 <dl>
    550 Two operators are provided to fetch and store cell pairs:
    551 
    552 <P>
    553 
    554 <code>
    555 <a href=dpans6.htm#6.1.0350>2@</a>  
    556 <a href=dpans6.htm#6.1.0310>2!</a>
    557 </code>
    558 </dl>
    559 <P>
    560 
    561 b) Manipulation on the stack
    562 <P>
    563 
    564 <dl>
    565 Additionally, these operators may be used to move cell pairs from, to
    566 and upon the stack:
    567 
    568 <P>
    569 
    570 <code>
    571 <a href=dpans6.htm#6.2.0340>2&gt;R</a>  
    572 <a href=dpans6.htm#6.1.0370>2DROP</a>  
    573 <a href=dpans6.htm#6.1.0380>2DUP</a>  
    574 <a href=dpans6.htm#6.1.0400>2OVER</a>  
    575 <a href=dpans6.htm#6.2.0415>2R&gt;</a>  
    576 <a href=dpans6.htm#6.1.0430>2SWAP</a>  
    577 <a href=dpans8.htm#8.6.2.0420>2ROT</a>
    578 </code>
    579 </dl>
    580 <P>
    581 
    582 c) Comparison
    583 <P>
    584 
    585 <dl>
    586 The following comparison operations are universally valid for cell
    587 pairs:
    588 
    589 <P>
    590 
    591 <code>
    592 <a href=dpans8.htm#8.6.1.1120>D=</a>  
    593 <a href=dpans8.htm#8.6.1.1080>D0=</a>
    594 </code>
    595 </dl>
    596 </dl>
    597 <P>
    598 
    599 
    600 <hr>
    601 <a name=A.3.1.4.1>
    602 <H4>A.3.1.4.1 Double-cell integers</H4>
    603 </a>
    604 
    605 If a double-cell integer is to be treated as signed, the following
    606 comparison and mathematical operations are valid:
    607 
    608 <P>
    609 
    610 <code>
    611 <a href=dpans8.htm#8.6.1.1040>D+</a>  
    612 <a href=dpans8.htm#8.6.1.1050>D-</a>  
    613 <a href=dpans8.htm#8.6.1.1110>D&lt;</a>  
    614 <a href=dpans8.htm#8.6.1.1075>D0&lt;</a>  
    615 <a href=dpans8.htm#8.6.1.1160>DABS</a>  
    616 <a href=dpans8.htm#8.6.1.1210>DMAX</a>  
    617 <a href=dpans8.htm#8.6.1.1220>DMIN</a>  
    618 <a href=dpans8.htm#8.6.1.1230>DNEGATE</a>  
    619 <a href=dpans8.htm#8.6.1.1820>M*/</a>  
    620 <a href=dpans8.htm#8.6.1.1830>M+</a>
    621 </code>
    622 <P>
    623 
    624 If a double-cell integer is to be treated as unsigned, the following
    625 comparison and mathematical operations are valid:
    626 
    627 <P>
    628 
    629 <code>
    630 D+  
    631 D-  
    632 <a href=dpans6.htm#6.1.2370>UM/MOD</a>  
    633 <a href=dpans8.htm#8.6.2.1270>DU&lt;</a>
    634 </code>
    635 <P>
    636 
    637 
    638 <hr>
    639 <a name=A.3.1.4.2>
    640 <H4>A.3.1.4.2 Character strings</H4>
    641 </a>
    642 
    643 See:
    644 <a href=dpansa3.htm#A.3.1.3.4>A.3.1.3.4</a> Counted Strings
    645 <P>
    646 
    647 
    648 <hr>
    649 <a name=A.3.2>
    650 <H2>A.3.2 The implementation environment</H2>
    651 </a>
    652 
    653 
    654 
    655 <hr>
    656 <a name=A.3.2.1>
    657 <H3>A.3.2.1 Numbers</H3>
    658 </a>
    659 
    660 Traditionally, Forth has been implemented on two's-complement machines
    661 where there is a one-to-one mapping of signed numbers to unsigned
    662 numbers - any single cell item can be viewed either as a signed or
    663 unsigned number.  Indeed, the signed representation of any positive
    664 number is identical to the equivalent unsigned representation.  Further,
    665 addresses are treated as unsigned numbers: there is no distinct pointer
    666 type.  Arithmetic ordering on two's complement machines allows + and -
    667 to work on both signed and unsigned numbers.  This arithmetic behavior
    668 is deeply embedded in common Forth practice.  As a consequence of these
    669 behaviors, the likely ranges of signed and unsigned numbers for
    670 implementations hosted on each of the permissible arithmetic
    671 architectures is:
    672 
    673 <P>
    674 <pre>
    675       ---------------------------------------------------------
    676       Arithmetic architecture  signed numbers  unsigned numbers
    677       ---------------------------------------------------------
    678       Two's complement         -n-1 to n       0 to 2n+1
    679       One's complement         -n to n         0 to n
    680       Signed magnitude         -n to n         0 to n
    681       ---------------------------------------------------------
    682 </pre>
    683 <P>
    684 
    685 where n is the largest positive signed number.  For all three
    686 architectures, signed numbers in the 0 to n range are bitwise identical
    687 to the corresponding unsigned number.  Note that unsigned numbers on a
    688 signed magnitude machine are equivalent to signed non-negative numbers
    689 as a consequence of the forced correspondence between addresses and
    690 unsigned numbers and of the required behavior of + and -.
    691 
    692 <P>
    693 
    694 For reference, these number representations may be defined by the way
    695 that 
    696 <a href=dpans6.htm#6.1.1910>NEGATE</a> is implemented:
    697 
    698 <P>
    699 
    700 
    701 <PRE>
    702 two's complement:       : NEGATE  INVERT 1+ ;
    703 one's complement:       : NEGATE  INVERT ;
    704 signed-magnitude:       : NEGATE  HIGH-BIT XOR ;
    705 </PRE>
    706 
    707 <P>
    708 
    709 where HIGH-BIT is a bit mask with only the most-significant bit set.
    710 Note that all of these number systems agree on the representation of
    711 non-negative numbers.
    712 
    713 <P>
    714 
    715 Per <A href=dpans3.htm#3.2.1.1>3.2.1.1</A> Internal number 
    716 representation and 
    717 <a href=dpans6.htm#6.1.0270>6.1.0270</a> 0=, the
    718 implementor must ensure that no standard or supported word return
    719 negative zero for any numeric (non-Boolean or flag) result.  Many
    720 existing programmer assumptions will be violated otherwise.
    721 
    722 <P>
    723 
    724 There is no requirement to implement circular unsigned arithmetic, nor
    725 to set the range of unsigned numbers to the full size of a cell.  There
    726 is historical precedent for limiting the range of u to that of +n, which
    727 is permissible when the cell size is greater than 16 bits.
    728 
    729 <P>
    730 
    731 
    732 <hr>
    733 <A name=A.3.2.1.2>
    734 <H4>A.3.2.1.2 Digit conversion</H4>
    735 </a>
    736 
    737 For example, an implementation might convert the characters <B>a</B>
    738 through <B>z</B> identically to the characters <B>A</B> through
    739 <B>Z</B>, or it might treat the characters <B>[</B> through <B>~</B>
    740 as additional digits with decimal values 36 through 71, respectively.
    741 
    742 <P>
    743 
    744 
    745 <hr>
    746 <a name=A.3.2.2>
    747 <H3>A.3.2.2 Arithmetic</H3>
    748 </a>
    749 
    750 
    751 <hr>
    752 <a name=A.3.2.2.1>
    753 <H4>A.3.2.2.1 Integer division</H4>
    754 </a>
    755 
    756 The Forth-79 Standard specifies that the signed division operators 
    757 (<a href=dpans6.htm#6.1.0230>/</a>,
    758 <a href=dpans6.htm#6.1.0240>/MOD</a>, 
    759 <a href=dpans6.htm#6.1.1890>MOD</a>, 
    760 <a href=dpans6.htm#6.1.0110>*/MOD</a>, 
    761 and 
    762 <a href=dpans6.htm#6.1.0100>*/</a>) 
    763 round non-integer quotients towards zero
    764 (symmetric division).  Forth-83 changed the semantics of these operators
    765 to round towards negative infinity (floored division).  Some in the
    766 Forth community have declined to convert systems and applications from
    767 the Forth-79 to the Forth-83 divide.  To resolve this issue, an ANS
    768 Forth system is permitted to supply either floored or symmetric
    769 operators.  In addition, ANS Forth systems must provide a floored
    770 division primitive 
    771 (<a href=dpans6.htm#6.1.1561>FM/MOD</a>), 
    772 a symmetric division primitive 
    773 (<a href=dpans6.htm#6.1.2214>SM/REM</a>),
    774 and a mixed precision multiplication operator 
    775 (<a href=dpans6.htm#6.1.1810>M*</a>).
    776 
    777 <P>
    778 
    779 This compromise protects the investment made in current Forth
    780 applications; Forth-79 and Forth-83 programs are automatically compliant
    781 with ANS Forth with respect to division.  In practice, the rounding
    782 direction rarely matters to applications.  However, if a program
    783 requires a specific rounding direction, it can use the floored division
    784 primitive FM/MOD or the symmetric division primitive SM/REM to construct
    785 a division operator of the desired flavor.  This simple technique can be
    786 used to convert Forth-79 and Forth-83 programs to ANS Forth without any
    787 analysis of the original programs.
    788 
    789 <P>
    790 
    791 
    792 <hr>
    793 <a name=A.3.2.2.2>
    794 <H4>A.3.2.2.2 Other integer operations</H4>
    795 </a>
    796 
    797 Whether underflow occurs depends on the data-type of the result.  For
    798 example, the phrase 
    799 <b><code>1 2 -</code></b> underflows if the result is unsigned and
    800 produces the valid signed result -1.
    801 
    802 <P>
    803 
    804 
    805 <hr>
    806 <a name=A.3.2.3>
    807 <H3>A.3.2.3 Stacks</H3>
    808 </a>
    809 
    810 The only data type in Forth which has concrete rather than abstract
    811 existence is the stack entry.  Even this primitive typing Forth only
    812 enforces by the hard reality of stack underflow or overflow.  The
    813 programmer must have a clear idea of the number of stack entries to be
    814 consumed by the execution of a word and the number of entries that will
    815 be pushed back to a stack by the execution of a word.  The observation
    816 of anomalous occurrences on the data stack is the first line of defense
    817 whereby the programmer may recognize errors in an application program.
    818 It is also worth remembering that multiple stack errors caused by
    819 erroneous application code are frequently of equal and opposite
    820 magnitude, causing complementary (and deceptive) results.
    821 
    822 <P>
    823 
    824 For these reasons and a host of other reasons, the one unambiguous,
    825 uncontroversial, and indispensable programming discipline observed since
    826 the earliest days of Forth is that of providing a stack diagram for all
    827 additions to the application dictionary with the exception of static
    828 constructs such as 
    829 <a href=dpans6.htm#6.1.2410>VARIABLE</a>s and 
    830 <a href=dpans6.htm#6.1.0950>CONSTANT</a>s.
    831 
    832 <P>
    833 
    834 
    835 <hr>
    836 <a name=A.3.2.3.2>
    837 <H4>A.3.2.3.2 Control-flow stack</H4>
    838 </a>
    839 
    840 The simplest use of control-flow words is to implement the basic control
    841 structures shown in figure A.1.
    842 
    843 <P>
    844 
    845 <a name=figure.A.1>*
    846 </a>
    847 <pre>
    848     ---------------------------------------------------------------
    849          |                 _____ |               _____ |
    850         < >-----  IF      |     \|     BEGIN    |     \|     BEGIN
    851          |      |         |  +-------+          |  +-------+
    852      +-------+  |         |  |       |          |  |       |
    853      |       |  |         |  +-------+          |  +-------+
    854      +-------+  |         |      |              |      |
    855          | _____|          -----< >    UNTIL     ------      AGAIN
    856          |/       THEN           |
    857          |                       |
    858     ---------------------------------------------------------------
    859                       Figure A.1 - The basic control-flow patterns.
    860 </pre>
    861 <P>
    862 
    863 Figure A.1 - The basic control-flow patterns.
    864 <P>
    865 
    866 In control flow every branch, or transfer of control, must terminate at
    867 some destination.  A natural implementation uses a stack to remember the
    868 origin of forward branches and the destination of backward branches.  At
    869 a minimum, only the location of each origin or destination must be
    870 indicated, although other implementation-dependent information also may
    871 be maintained.
    872 
    873 <P>
    874 
    875 An origin is the location of the branch itself.  A destination is where
    876 control would continue if the branch were taken.  A destination is
    877 needed to resolve the branch address for each origin, and conversely, if
    878 every control-flow path is completed no unused destinations can remain.
    879 
    880 <P>
    881 
    882 With the addition of just three words 
    883 (<a href=dpans15.htm#15.6.2.0702>AHEAD</a>, 
    884 <a href=dpans15.htm#15.6.2.1020>CS-ROLL</a> and 
    885 <a href=dpans15.htm#15.6.2.1015>CS-PICK</a>), the
    886 basic control-flow words supply the primitives necessary to compile a
    887 variety of transportable control structures.  The abilities required are
    888 compilation of forward and backward conditional and unconditional
    889 branches and compile-time management of branch origins and destinations.
    890 Table A.1 shows the desired behavior.
    891 
    892 <P>
    893 
    894 The requirement that control-flow words are properly balanced by other
    895 control-flow words makes reasonable the description of a compile-time
    896 implementation-defined control-flow stack.  There is no prescription as
    897 to how the control-flow stack is implemented, e.g., data stack, linked
    898 list, special array.  Each element of the control-flow stack mentioned
    899 above is the same size.
    900 
    901 <P>
    902 <a name=table.a.1>*
    903 </a>
    904 <pre>
    905                  Table A.1 - Compilation behavior of control-flow words
    906    ---------------------------------------------------------------------------
    907    at compile time,
    908    word:    supplies:  resolves:  is used to:
    909    ---------------------------------------------------------------------------
    910    IF       orig                  mark origin of forward conditional branch
    911    THEN                orig       resolve IF or AHEAD
    912    BEGIN    dest                  mark backward destination
    913    AGAIN               dest       resolve with backward unconditional branch
    914    UNTIL               dest       resolve with backward conditional branch
    915    AHEAD    orig                  mark origin of forward unconditional branch
    916    CS-PICK                        copy item on control-flow stack
    917    CS-ROLL                        reorder items on control-flow stack
    918    --------------------------------------------------------------------------
    919 </pre>
    920 <P>
    921 
    922 With these tools, the remaining basic control-structure elements, shown
    923 in 
    924 <a href=dpansa3.htm#figure.a.2>figure A.2</a>, 
    925 can be defined.  The stack notation used here for
    926 immediate words is ( compilation / execution ).
    927 
    928 <P>
    929 
    930 <PRE>
    931 : WHILE  ( dest -- orig dest / flag -- )
    932                             \ conditional exit from loops
    933 	POSTPONE IF         \ conditional forward branch
    934            1 CS-ROLL        \ keep dest on top
    935 ; IMMEDIATE
    936 
    937 
    938 : REPEAT  ( orig dest -- / -- )
    939                             \ resolve a single WHILE and return to BEGIN
    940            POSTPONE AGAIN   \ uncond. backward branch to dest
    941            POSTPONE THEN    \ resolve forward branch from orig
    942 ; IMMEDIATE
    943 
    944 : ELSE  ( orig1 -- orig2 / -- )
    945                             \ resolve IF supplying alternate execution
    946         POSTPONE AHEAD      \ unconditional forward branch orig2
    947            1 CS-ROLL        \ put orig1 back on top
    948            POSTPONE THEN    \ resolve forward branch from orig1
    949 ; IMMEDIATE
    950 </PRE>
    951 
    952 <P>
    953 <a name=figure.a.2>*
    954 </a>
    955 <pre>
    956      -----------------------------------------------
    957              |                 _____ |
    958             < >-----  IF      |     \|        BEGIN
    959              |      |         |  +-------+
    960          +-------+  |         |  |       |
    961          |       |  |         |  +-------+
    962          +-------+  |         |      |
    963              | _____|         |     < >-----  WHILE
    964        _____/ /       ELSE    |      |      |
    965       |      |                |  +-------+  |
    966       |  +-------+            |  |       |  |
    967       |  |       |            |  +-------+  |
    968       |  +-------+            |      |      |
    969       |_____ |                |_____/  _____|
    970             \|        THEN            /       REPEAT
    971              |                       |
    972     ----------------------------------------------
    973     Figure A.2 - Additional basic control-flow patterns.
    974 </pre>
    975 <P>
    976 
    977 Forth control flow provides a solution for well-known problems with
    978 strictly structured programming.
    979 
    980 <P>
    981 
    982 The basic control structures can be supplemented, as shown in the
    983 examples in 
    984 <a href=dpansa3.htm#figure.a.3>figure A.3</a>, 
    985 with additional WHILEs in BEGIN ...  UNTIL and
    986 BEGIN ...  WHILE ...  REPEAT structures.  However, for each additional
    987 WHILE there must be a THEN at the end of the structure.  THEN completes
    988 the syntax with WHILE and indicates where to continue execution when the
    989 WHILE transfers control.  The use of more than one additional WHILE is
    990 possible but not common.  Note that if the user finds this use of THEN
    991 undesirable, an alias with a more likable name could be defined.
    992 
    993 <P>
    994 
    995 Additional actions may be performed between the control flow word (the
    996 REPEAT or UNTIL) and the THEN that matches the additional WHILE.
    997 Further, if additional actions are desired for normal termination and
    998 early termination, the alternative actions may be separated by the
    999 ordinary Forth ELSE.  The termination actions are all specified after
   1000 the body of the loop.
   1001 
   1002 <P>
   1003 <a name=figure.a.3>*
   1004 </a>
   1005 <pre>
   1006     --------------------------------------------------
   1007      _____ |                      _____ |
   1008     |     \|         BEGIN       |     \|        BEGIN
   1009     |  +-------+                 |  +-------+
   1010     |  |       |                 |  |       |
   1011     |  +-------+                 |  +-------+
   1012     |      |                     |      |
   1013     |     < >------  WHILE       |     < >-----  WHILE
   1014     |      |       |             |      |      |
   1015     |  +-------+   |             |  +-------+  |
   1016     |  |       |   |             |  |       |  |
   1017     |  +-------+   |             |  +-------+  |
   1018     |      |       |             |      |      |
   1019     |     < >----  | WHILE        -----< >     | UNTIL
   1020     |      |     | |                    |      |
   1021     |  +-------+ | |                +-------+  |
   1022     |  |       | | |                |       |  |
   1023     |  +-------+ | |                +-------+  |
   1024     |      | ____| |                    | _____/
   1025      \____/ /      | REPEAT       _____/ /       ELSE
   1026            |       |             |      |
   1027        +-------+   |             |  +-------+
   1028        |       |   |             |  |       |
   1029        +-------+   |             |  +-------+
   1030            | ______/              \____ |
   1031            |/        THEN              \|        THEN
   1032            |                            |
   1033     ---------------------------------------------------
   1034     Figure A.3 - Extended control-flow pattern examples.
   1035 </pre>
   1036 <P>
   1037 
   1038 Note that REPEAT creates an anomaly when matching the WHILE with ELSE or
   1039 THEN, most notable when compared with the BEGIN...UNTIL case.  That is,
   1040 there will be one less ELSE or THEN than there are WHILEs because REPEAT
   1041 resolves one THEN.  As above, if the user finds this count mismatch
   1042 undesirable, REPEAT could be replaced in-line by its own definition.
   1043 
   1044 <P>
   1045 
   1046 Other loop-exit control-flow words, and even other loops, can be
   1047 defined.  The only requirements are that the control-flow stack is
   1048 properly maintained and manipulated.
   1049 
   1050 <P>
   1051 
   1052 The simple implementation of the ANS Forth CASE structure below is an
   1053 example of control structure extension.  Note the maintenance of the
   1054 data stack to prevent interference with the possible control-flow stack
   1055 usage.
   1056 
   1057 <P>
   1058 
   1059 
   1060 <PRE>
   1061 0 CONSTANT CASE IMMEDIATE  ( init count of OFs )
   1062 
   1063 : OF  ( #of -- orig #of+1 / x -- )
   1064     1+    ( count OFs )
   1065     >R    ( move off the stack in case the control-flow )
   1066           ( stack is the data stack. )
   1067     POSTPONE OVER  POSTPONE = ( copy and test case value)
   1068     POSTPONE IF    ( add orig to control flow stack )
   1069     POSTPONE DROP  ( discards case value if = )
   1070     R>             ( we can bring count back now )
   1071 ; IMMEDIATE
   1072 
   1073 : ENDOF ( orig1 #of -- orig2 #of )
   1074     >R   ( move off the stack in case the control-flow )
   1075          ( stack is the data stack. )
   1076     POSTPONE ELSE
   1077     R>   ( we can bring count back now )
   1078 ; IMMEDIATE
   1079 
   1080 : ENDCASE  ( orig1..orign #of -- )
   1081     POSTPONE DROP  ( discard case value )
   1082     0 ?DO
   1083       POSTPONE THEN
   1084     LOOP
   1085 ; IMMEDIATE
   1086 </PRE>
   1087 
   1088 <P>
   1089 
   1090 <hr>
   1091 <a name=A.3.2.3.3>
   1092 <H4>A.3.2.3.3 Return stack</H4>
   1093 </a>
   1094 
   1095 The restrictions in 
   1096 <a href=dpans3.htm#3.2.3.3>section 3.2.3.3</a> Return stack are necessary if
   1097 implementations are to be allowed to place loop parameters on the return
   1098 stack.
   1099 
   1100 <P>
   1101 
   1102 
   1103 <hr>
   1104 <a name=A.3.2.6>
   1105 <H3>A.3.2.6 Environmental queries</H3>
   1106 </a>
   1107 
   1108 The size in address units of various data types may be determined by
   1109 phrases such as <code><b>1 CHARS</code></b>.  
   1110 Similarly, alignment may be determined by
   1111 phrases such as <code><b>1 ALIGNED</code></b>.
   1112 
   1113 <P>
   1114 
   1115 The environmental queries are divided into two groups: those that always
   1116 produce the same value and those that might not.  The former groups
   1117 include entries such as MAX-N.  This information is fixed by the
   1118 hardware or by the design of the Forth system; a user is guaranteed that
   1119 asking the question once is sufficient.
   1120 
   1121 <P>
   1122 
   1123 The other group of queries are for things that may legitimately change
   1124 over time.  For example an application might test for the presence of
   1125 the Double Number word set using an environment query.  If it is
   1126 missing, the system could invoke a system-dependent process to load the
   1127 word set.  The system is permitted to change 
   1128 <a href=dpans6.htm#6.1.1345>ENVIRONMENT?</a>'s database so
   1129 that subsequent queries about it indicate that it is present.
   1130 
   1131 <P>
   1132 
   1133 Note that a query that returns an <B>unknown</B> response could produce
   1134 a <B>known</B> result on a subsequent query.
   1135 
   1136 <P>
   1137 
   1138 
   1139 <hr>
   1140 <a name=A.3.3>
   1141 <H2>A.3.3 The Forth dictionary</H2>
   1142 </a>
   1143 
   1144 A Standard Program may redefine a standard word with a non-standard
   1145 definition.  The program is still Standard (since it can be built on any
   1146 Standard System), but the effect is to make the combined entity
   1147 (Standard System plus Standard Program) a non-standard system.
   1148 
   1149 <P>
   1150 
   1151 
   1152 <hr>
   1153 <a name=A.3.3.1>
   1154 <H3>A.3.3.1 Name space</H3>
   1155 </a>
   1156 
   1157 
   1158 <hr>
   1159 <a name=A.3.3.1.2>
   1160 <H4>A.3.3.1.2 Definition names</H4>
   1161 </a>
   1162 
   1163 The language in this section is there to ensure the portability of
   1164 Standard Programs.  If a program uses something outside the Standard
   1165 that it does not provide itself, there is no guarantee that another
   1166 implementation will have what the program needs to run.  There is no
   1167 intent whatsoever to imply that all Forth programs will be somehow
   1168 lacking or inferior because they are not standard; some of the finest
   1169 jewels of the programmer's art will be non-standard.  At the same time,
   1170 the committee is trying to ensure that a program labeled <B>Standard</B>
   1171 will meet certain expectations, particularly with regard to portability.
   1172 
   1173 <P>
   1174 
   1175 In many system environments the input source is unable to supply certain
   1176 non-graphic characters due to external factors, such as the use of those
   1177 characters for flow control or editing.  In addition, when interpreting
   1178 from a text file, the parsing function specifically treats non-graphic
   1179 characters like spaces; thus words received by the text interpreter will
   1180 not contain embedded non-graphic characters.  To allow implementations
   1181 in such environments to call themselves Standard, this minor restriction
   1182 on Standard Programs is necessary.
   1183 
   1184 <P>
   1185 
   1186 A Standard System is allowed to permit the creation of definition names
   1187 containing non-graphic characters.  Historically, such names were used
   1188 for keyboard editing functions and <B>invisible</B> words.
   1189 
   1190 <P>
   1191 
   1192 <hr>
   1193 <a name=A.3.3.2>
   1194 <H3>A.3.3.2 Code space</H3>
   1195 </a>
   1196 
   1197 
   1198 <hr>
   1199 <a name=A.3.3.3>
   1200 <H3>A.3.3.3 Data space</H3>
   1201 </a>
   1202 
   1203 The words 
   1204 <a href=dpans6.htm#6.2.0060>#TIB</a>, 
   1205 <a href=dpans6.htm#6.1.0560>&gt;IN</a>, 
   1206 <a href=dpans6.htm#6.1.0750>BASE</a>, 
   1207 <a href=dpans7.htm#7.6.1.0790>BLK</a>, 
   1208 <a href=dpans7.htm#7.6.2.2190>SCR</a>, 
   1209 <a href=dpans6.htm#6.1.2216>SOURCE</a>, 
   1210 <a href=dpans6.htm#6.2.2218>SOURCE-ID</a>, 
   1211 <a href=dpans6.htm#6.1.2250>STATE</a>, and 
   1212 <a href=dpans6.htm#6.2.2290>TIB</a>
   1213 contain information used by the Forth system in its operation and may be
   1214 of use to the application.  Any assumption made by the application about
   1215 data available in the Forth system it did not store other than the data
   1216 just listed is an environmental dependency.
   1217 
   1218 <P>
   1219 
   1220 There is no point in specifying (in the Standard) both what is and what
   1221 is not addressable.
   1222 
   1223 <P>
   1224 
   1225 A Standard Program may NOT address:
   1226 <P>
   1227 
   1228 <UL>
   1229 <LI>Directly into the data or return stacks;
   1230 <LI>Into a definition's data field if not stored by the application.
   1231 </ul>
   1232 <P>
   1233 
   1234 The read-only restrictions arise because some Forth systems run from ROM
   1235 and some share I/O buffers with other users or systems. Portable
   1236 programs cannot know which areas are affected, hence the general restrictions.
   1237 
   1238 
   1239 <P>
   1240 
   1241 <hr>
   1242 <a name=A.3.3.3.1>
   1243 <H4>A.3.3.3.1 Address alignment</H4>
   1244 </a>
   1245 
   1246 Many processors have restrictions on the addresses that can be used by
   1247 memory access instructions.  For example, on a Motorola 68000, 16-bit or
   1248 32-bit data can be accessed only at even addresses.  Other examples
   1249 include RISC architectures where 16-bit data can be loaded or stored
   1250 only at even addresses and 32-bit data only at addresses that are
   1251 multiples of four.
   1252 
   1253 <P>
   1254 
   1255 An implementor of ANS Forth can handle these alignment restrictions in
   1256 one of two ways.  Forth's memory access words 
   1257 (<a href=dpans6.htm#6.1.0650>@</a>, 
   1258 <a href=dpans6.htm#6.1.0010>!</a>, 
   1259 <a href=dpans6.htm#6.1.0130>+!</a>, 
   1260 etc.) could be
   1261 implemented in terms of smaller-width access instructions which have no
   1262 alignment restrictions.  For example, on a 68000 Forth with 16-bit
   1263 cells, @ could be implemented with two 68000 byte-fetch instructions and
   1264 a reassembly of the bytes into a 16-bit cell.  Although this conceals
   1265 hardware restrictions from the programmer, it is inefficient, and may
   1266 have unintended side effects in some hardware environments.  An
   1267 alternate implementation of ANS Forth could define each memory-access
   1268 word using the native instructions that most closely match the word's
   1269 function.  On a 68000 Forth with 16-bit cells, @ would use the 68000's
   1270 16-bit move instruction.  In this case, responsibility for giving @ a
   1271 correctly-aligned address falls on the programmer.  A portable ANS Forth
   1272 program must assume that alignment may be required and follow the
   1273 requirements of this section.
   1274 
   1275 <P>
   1276 
   1277 <hr>
   1278 <a name=A.3.3.3.2>
   1279 <H4>A.3.3.3.2 Contiguous regions</H4>
   1280 </a>
   1281 
   1282 The data space of a Forth system comes in discontinuous regions! The
   1283 location of some regions is provided by the system, some by the program.
   1284 Data space is contiguous within regions, allowing address arithmetic to
   1285 generate valid addresses only within a single region.  A Standard
   1286 Program cannot make any assumptions about the relative placement of
   1287 multiple regions in memory.
   1288 
   1289 <P>
   1290 
   1291 <a href=dpans3.htm#3.3.3.2>Section 3.3.3.2</a>
   1292 does prescribe conditions under which contiguous regions
   1293 of data space may be obtained.  For example:
   1294 
   1295 <PRE>
   1296 	CREATE TABLE   1 C, 2 C, ALIGN 1000 , 2000 ,
   1297 </PRE>
   1298 <P>
   1299 
   1300 makes a table whose address is returned by TABLE.  In accessing this table,
   1301 
   1302 
   1303 <PRE>
   1304 TABLE C@                        will return 1
   1305 TABLE CHAR+ C@                  will return 2
   1306 TABLE 2 CHARS + ALIGNED @       will return 1000
   1307 TABLE 2 CHARS + ALIGNED CELL+ @ will return 2000.
   1308 </PRE>
   1309 
   1310 <P>
   1311 
   1312 Similarly,
   1313 
   1314 <PRE>
   1315 	CREATE DATA   1000 ALLOT
   1316 </PRE>
   1317 <P>
   1318 
   1319 makes an array 1000 address units in size.  A more portable strategy would
   1320 define the array in application units, such as:
   1321 
   1322 <P>
   1323 
   1324 
   1325 <PRE>
   1326 	500 CONSTANT NCELLS
   1327 	CREATE CELL-DATA  NCELLS CELLS ALLOT
   1328 </PRE>
   1329 
   1330 <P>
   1331 
   1332 This array can be indexed like this:
   1333 
   1334 <PRE>
   1335 	: LOOK   NCELLS 0 DO  CELL-DATA I CELLS + ? LOOP ;
   1336 </PRE>
   1337 
   1338 <P>
   1339 
   1340 
   1341 <hr>
   1342 <a name=A.3.3.3.6>
   1343 <H4>A.3.3.3.6 Other transient regions</H4>
   1344 </a>
   1345 
   1346 In many existing Forth systems, these areas are at 
   1347 <a href=dpans6.htm#6.1.1650>HERE</a> 
   1348 or just beyond
   1349 it, hence the many restrictions.
   1350 
   1351 <P>
   1352 
   1353 (2*n)+2 is the size of a character string containing the unpunctuated
   1354 binary representation of the maximum double number with a leading minus
   1355 sign and a trailing space.
   1356 
   1357 <P>
   1358 
   1359 <b>Implementation note:</b> Since the minimum value of n is 16, the absolute
   1360 minimum size of the pictured numeric output string is 34 characters.
   1361 But if your implementation has a larger n, you must also increase the
   1362 size of the pictured numeric output string.
   1363 
   1364 <P>
   1365 
   1366 <hr>
   1367 <a name=A.3.4>
   1368 <H2>A.3.4 The Forth text interpreter</H2>
   1369 </a>
   1370 
   1371 
   1372 <hr>
   1373 <a name=A.3.4.3>
   1374 <H3>A.3.4.3 Semantics</H3>
   1375 </a>
   1376 
   1377 The <B>initiation semantics</B> correspond to the code that is executed
   1378 upon entering a definition, analogous to the code executed by 
   1379 <a href=dpans6.htm#6.1.1380>EXIT</a> upon
   1380 leaving a definition.  The <B>run-time semantics</B> correspond to code
   1381 fragments, such as literals or branches, that are compiled inside colon
   1382 definitions by words with explicit compilation semantics.
   1383 
   1384 <P>
   1385 
   1386 In a Forth cross-compiler, the execution semantics may be specified to
   1387 occur in the host system only, the target system only, or in both
   1388 systems.  For example, it may be appropriate for words such as 
   1389 <a href=dpans6.htm#6.1.0890>CELLS</a> to
   1390 execute on the host system returning a value describing the target, for
   1391 colon definitions to execute only on the target, and for 
   1392 <a href=dpans6.htm#6.1.0950>CONSTANT</a> and
   1393 <a href=dpans6.htm#6.1.2410>VARIABLE</a> 
   1394 to have execution behaviors on both systems.  Details of
   1395 cross-compiler behavior are beyond the scope of this Standard.
   1396 
   1397 <P>
   1398 
   1399 <hr>
   1400 <a name=A.3.4.3.2>
   1401 <H4>A.3.4.3.2 Interpretation semantics</H4>
   1402 </a>
   1403 
   1404 For a variety of reasons, this Standard does not define interpretation
   1405 semantics for every word.  Examples of these words are 
   1406 <a href=dpans6.htm#6.1.0580>&gt;R</a>, 
   1407 <a href=dpans6.htm#6.1.0190>."</a>, 
   1408 <a href=dpans6.htm#6.1.1240>DO</a>, and
   1409 <a href=dpans6.htm#6.1.1700>IF</a>.  
   1410 Nothing in this Standard precludes an implementation from providing
   1411 interpretation semantics for these words, such as interactive
   1412 control-flow words.  However, a Standard Program may not use them in
   1413 interpretation state.
   1414 
   1415 <P>
   1416 
   1417 <hr>
   1418 <a name=A.3.4.5>
   1419 <H3>A.3.4.5 Compilation</H3>
   1420 </a>
   1421 
   1422 Compiler recursion at the definition level consumes excessive resources,
   1423 especially to support locals.  The Technical Committee does not believe
   1424 that the benefits justify the costs.  Nesting definitions is also not
   1425 common practice and won't work on many systems.
   1426 
   1427 <P>
   1428 
   1429 <hr>
   1430 <a href=dpans.htm#toc><IMG   src="up.gif" ></A>    Table of Contents 
   1431 <BR>
   1432 <a href=dpansa4.htm><IMG   src="right.gif" ></A>
   1433 Next Section
   1434 <P>
   1435 </BODY>
   1436 </HTML>