umouse

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

DPANSC.HTM (38172B)


      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=dpansb.htm><img src=left.gif
     12  width=26 height=26 align=ALIGN border=0></a>
     13 <a href=dpansd.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=C.>Table of Contents</a>
     20 </td>
     21 </tr>
     22 </table>
     23 <p>
     24 <hr size=4>
     25 
     26 <H1>C. Perspective (informative annex)</H1>
     27 
     28 The purpose of this section is to provide an informal overview of Forth as a
     29 language, illustrating its history, most prominent features, usage, and common
     30 implementation techniques.  Nothing in this section should be considered as
     31 binding upon either implementors or users.  A list of books and articles is
     32 given in Annex B for those interested in learning more about Forth.
     33 
     34 <P>
     35 
     36 <hr>
     37 <A name=C.1>
     38 <H2>C.1 Features of Forth</H2>
     39 </a>
     40 
     41 Forth provides an interactive programming environment.  Its primary uses have
     42 been in scientific and industrial applications such as instrumentation,
     43 robotics, process control, graphics and image processing, artificial
     44 intelligence and business applications.  The principal advantages of Forth
     45 include rapid, interactive software development and efficient use of computer
     46 hardware.
     47 
     48 <P>
     49 
     50 Forth is often spoken of as a language because that is its most visible
     51 aspect.  But in fact, Forth is both more and less than a conventional
     52 programming language:  more in that all the capabilities normally associated
     53 with a large portfolio of separate programs (compilers, editors, etc.) are
     54 included within its range and less in that it lacks (deliberately) the complex
     55 syntax characteristic of most high-level languages.
     56 
     57 <P>
     58 
     59 The original implementations of Forth were stand-alone systems that included
     60 functions normally performed by separate operating systems, editors,
     61 compilers, assemblers, debuggers and other utilities.  A single simple,
     62 consistent set of rules governed this entire range of capabilities.  Today,
     63 although very fast stand-alone versions are still marketed for many
     64 processors, there are also many versions that run co-resident with
     65 conventional operating systems such as MS-DOS and UNIX.
     66 
     67 <P>
     68 
     69 Forth is not derived from any other language.  As a result, its appearance and
     70 internal characteristics may seem unfamiliar to new users.  But Forth's
     71 simplicity, extreme modularity, and interactive nature offset the initial
     72 strangeness, making it easy to learn and use.  A new Forth programmer must
     73 invest some time mastering its large command repertoire.  After a month or so
     74 of full-time use of Forth, that programmer could understand more of its
     75 internal working than is possible with conventional operating systems and
     76 compilers.
     77 
     78 <P>
     79 
     80 The most unconventional feature of Forth is its extensibility.  The
     81 programming process in Forth consists of defining new <B>words</B> -
     82 actually new commands in the language.  These may be defined in terms of
     83 previously defined words, much as one teaches a child concepts by
     84 explaining them in terms of previously understood concepts.  Such words
     85 are called <B>high-level definitions</B>.  Alternatively, new words may
     86 also be defined in assembly code, since most Forth implementations
     87 include an assembler for the host processor.
     88 
     89 <P>
     90 
     91 This extensibility facilitates the development of special application
     92 languages for particular problem areas or disciplines.
     93 
     94 <P>
     95 
     96 Forth's extensibility goes beyond just adding new commands to the language.
     97 With equivalent ease, one can also add new kinds of words.  That is, one may
     98 create a word which itself will define words.  In creating such a defining
     99 word the programmer may specify a specialized behavior for the words it will
    100 create which will be effective at compile time, at run-time, or both.  This
    101 capability allows one to define specialized data types, with complete control
    102 over both structure and behavior.  Since the run-time behavior of such words
    103 may be defined either in high-level or in code, the words created by this new
    104 defining word are equivalent to all other kinds of Forth words in performance.
    105 Moreover, it is even easy to add new compiler directives to implement special
    106 kinds of loops or other control structures.
    107 
    108 <P>
    109 
    110 Most professional implementations of Forth are written in Forth.  Many
    111 Forth systems include a <B>meta-compiler</B> which allows the user to
    112 modify the internal structure of the Forth system itself.
    113 
    114 <P>
    115 
    116 <hr>
    117 <A name=C.2>
    118 <H2>C.2 History of Forth</H2>
    119 </a>
    120 
    121 Forth was invented by Charles H. Moore.  A direct outgrowth of Moore's work in
    122 the 1960's, the first program to be called Forth was written in about 1970.
    123 The first complete implementation was used in 1971 at the National Radio
    124 Astronomy Observatory's 11-meter radio telescope in Arizona.  This system was
    125 responsible for pointing and tracking the telescope, collecting data and
    126 recording it on magnetic tape, and supporting an interactive graphics terminal
    127 on which an astronomer could analyze previously recorded data.  The
    128 multi-tasking nature of the system allowed all these functions to be performed
    129 concurrently, without timing conflicts or other interference - a very advanced
    130 concept for that time.
    131 
    132 <P>
    133 
    134 The system was so useful that astronomers from all over the world began asking
    135 for copies.  Its use spread rapidly, and in 1976 Forth was adopted as a
    136 standard language by the International Astronomical Union.
    137 
    138 <P>
    139 
    140 In 1973, Moore and colleagues formed FORTH, Inc.  to explore commercial
    141 uses of the language.  FORTH, Inc.  developed multi-user versions of
    142 Forth on minicomputers for diverse projects ranging from data bases to
    143 scientific applications such as image processing.  In 1977, FORTH, Inc.
    144 developed a version for the newly introduced 8-bit microprocessors
    145 called <B>microFORTH</B>, which was successfully used in embedded
    146 microprocessor applications in the United States, Britain and Japan.
    147 
    148 <P>
    149 
    150 Stimulated by the volume marketing of microFORTH, a group of computer
    151 hobbyists in Northern California became interested in Forth, and in 1978
    152 formed the Forth Interest Group (FIG).  They developed a simplified model
    153 which they implemented on several microprocessors and published listings and
    154 disks at very low cost.  Interest in Forth spread rapidly, and today there are
    155 chapters of the Forth Interest Group throughout the U.S. and in over fifteen
    156 countries.
    157 
    158 <P>
    159 
    160 By 1980, a number of new Forth vendors had entered the market with versions of
    161 Forth based upon the FIG model.  Primarily designed for personal computers,
    162 these relatively inexpensive Forth systems have been distributed very widely.
    163 
    164 <P>
    165 
    166 
    167 <hr>
    168 <A name=C.3>
    169 <H2>C.3 Hardware implementations of Forth</H2>
    170 </a>
    171 
    172 The internal architecture of Forth simulates a computer with two stacks, a set
    173 of registers, and other standardized features.  As a result, it was almost
    174 inevitable that someone would attempt to build a hardware representation of an
    175 actual Forth computer.
    176 
    177 <P>
    178 
    179 In the early 1980's, Rockwell produced a 6502-variant with Forth primitives in
    180 on-board ROM, the Rockwell 65F11.  This chip has been used successfully in
    181 many embedded microprocessor applications.  In the mid-1980's Zilog developed
    182 the z8800 (Super8) which offered ENTER (nest), EXIT (unnest) and NEXT in
    183 microcode.
    184 
    185 <P>
    186 
    187 In 1981, Moore undertook to design a chip-level implementation of the Forth
    188 virtual machine.  Working first at FORTH, Inc. and subsequently with the
    189 start-up company NOVIX, formed to develop the chip, Moore completed the design
    190 in 1984, and the first prototypes were produced in early 1985.  More recently,
    191 Forth processors have been developed by Harris Semiconductor Corp., Johns
    192 Hopkins University, and others.
    193 
    194 <P>
    195 
    196 
    197 
    198 <hr>
    199 <A name=C.4>
    200 <H2>C.4 Standardization efforts</H2>
    201 </a>
    202 
    203 The first major effort to standardize Forth was a meeting in Utrecht in 1977.
    204 The attendees produced a preliminary standard, and agreed to meet the
    205 following year.  The 1978 meeting was also attended by members of the newly
    206 formed Forth Interest Group.  In 1979 and 1980 a series of meetings attended
    207 by both users and vendors produced a more comprehensive standard called
    208 Forth-79.
    209 
    210 <P>
    211 
    212 Although Forth-79 was very influential, many Forth users and vendors found
    213 serious flaws in it, and in 1983 a new standard called Forth-83 was released.
    214 
    215 <P>
    216 
    217 Encouraged by the widespread acceptance of Forth-83, a group of users and
    218 vendors met in 1986 to investigate the feasibility of an American National
    219 Standard.  The X3J14 Technical Committee for ANS Forth held its first meeting
    220 in 1987.  This Standard is the result.
    221 
    222 <P>
    223 
    224 
    225 <hr>
    226 <A name=C.5>
    227 <H2>C.5 Programming in Forth</H2>
    228 </a>
    229 
    230 Forth is an English-like language whose elements (called <B>words</B>)
    231 are named data items, procedures, and defining words capable of creating
    232 data items with customized characteristics.  Procedures and defining
    233 words may be defined in terms of previously defined words or in machine
    234 code, using an embedded assembler.
    235 
    236 <P>
    237 
    238 Forth <B>words</B> are functionally analogous to subroutines in other
    239 languages.  They are also equivalent to commands in other languages -
    240 Forth blurs the distinction between linguistic elements and functional
    241 elements.
    242 
    243 <P>
    244 
    245 Words are referred to either from the keyboard or in program source by
    246 name.  As a result, the term <B>word</B> is applied both to program (and
    247 linguistic) units and to their text names.  In parsing text, Forth
    248 considers a word to be any string of characters bounded by spaces.
    249 There are a few special characters that cannot be included in a word or
    250 start a word: space (the universal delimiter), CR (which ends terminal
    251 input), and backspace or DEL (for backspacing during keyboard input).
    252 Many groups adopt naming conventions to improve readability.  Words
    253 encountered in text fall into three categories: defined words (i.e.,
    254 Forth routines), numbers, and undefined words.  For example, here are
    255 four words:
    256 
    257 
    258 <PRE>
    259 	<a href=dpans6.htm#6.1.1650>HERE</a>      <a href=dpans6.htm#6.1.1250>DOES></a>      <a href=dpans6.htm#6.1.0010>!</a>      8493
    260 </PRE>
    261 
    262 <P>
    263 
    264 The first three are standard-defined words.  This means that they have
    265 entries in Forth's dictionary, described below, explaining what Forth is
    266 to do when these words are encountered.  The number <B>8493</B> will
    267 presumably not be found in the dictionary, and Forth will convert it to
    268 binary and place it on its push-down stack for parameters.  When Forth
    269 encounters an undefined word and cannot convert it to a number, the word
    270 is returned to the user with an exception message.
    271 
    272 <P>
    273 
    274 Architecturally, Forth words adhere strictly to the principles of
    275 <B>structured programming</B>:
    276 
    277 <UL>
    278 <LI>Words must be defined before they are used.
    279 <LI>Logical flow is restricted to sequential, conditional, and
    280 iterative patterns. Words are included to implement the most useful
    281 program control structures.
    282 <LI>The programmer works with many small, independent modules
    283 (words) for maximum testability and reliability.
    284 </UL>
    285 <P>
    286 
    287 Forth is characterized by five major elements: a dictionary, two
    288 push-down stacks, interpreters, an assembler, and virtual storage.
    289 Although each of these may be found in other systems, the combination
    290 produces a synergy that yields a powerful and flexible system.
    291 
    292 <P>
    293 
    294 
    295 <hr>
    296 <A name=C.5.1>
    297 <H3>C.5.1 The Forth dictionary</H3>
    298 </a>
    299 
    300 A Forth program is organized into a dictionary that occupies most of the
    301 memory used by the system.  This dictionary is a threaded list of
    302 variable-length items, each of which defines a word.  The content of
    303 each definition depends upon the type of word (data item, constant,
    304 sequence of operations, etc.).  The dictionary is extensible, usually
    305 growing toward high memory.  On some multi-user systems individual users
    306 have private dictionaries, each of which is connected to a shared system
    307 dictionary.
    308 
    309 <P>
    310 
    311 Words are added to the dictionary by <B>defining words</B>, of which the
    312 most commonly used is : 
    313 (<a href=dpans6.htm#6.1.0450>colon</a>).  
    314 When : is executed, it constructs a
    315 definition for the word that follows it.  In classical implementations,
    316 the content of this definition is a string of addresses of previously
    317 defined words which will be executed in turn whenever the word being
    318 defined is invoked.  The definition is terminated by ; 
    319 (<a href=dpans6.htm#6.1.0460>semicolon</a>).  
    320 For
    321 example, here is a definition:
    322 
    323 
    324 <PRE>
    325 	: RECEIVE  ( -- addr n )  PAD DUP 32 ACCEPT ;
    326 </PRE>
    327 
    328 <P>
    329 
    330 The name of the new word is RECEIVE.  The comment (in parentheses)
    331 indicates that it requires no parameters and will return an address and
    332 count on the data stack.  When RECEIVE is executed, it will perform the
    333 words in the remainder of the definition in sequence.  The word 
    334 <a href=dpans6.htm#6.2.2000>PAD</a>
    335 places on the stack the address of a scratch pad used to handle strings.
    336 <a href=dpans6.htm#6.1.1290>DUP</a> 
    337 duplicates the top stack item, so we now have two copies of the
    338 address.  The number 32 is also placed on the stack.  The word 
    339 <a href=dpans6.htm#6.1.0695>ACCEPT</a>
    340 takes an address (provided by PAD) and length (32) on the stack, accepts
    341 from the keyboard a string of up to 32 characters which will be placed
    342 at the specified address, and returns the number of characters received.
    343 The copy of the scratch-pad address remains on the stack below the count
    344 so that the routine that called RECEIVE can use it to pick up the
    345 received string.
    346 
    347 <P>
    348 
    349 
    350 <hr>
    351 <A name=C.5.2>
    352 <H3>C.5.2 Push-down stacks</H3>
    353 </a>
    354 
    355 The example above illustrates the use of push-down stacks for passing
    356 parameters between Forth words.  Forth maintains two push-down stacks,
    357 or LIFO lists.  These provide communication between Forth words plus an
    358 efficient mechanism for controlling logical flow.  A stack contains
    359 16-bit items on 8-bit and 16-bit computers, and 32-bit items on 32-bit
    360 processors.  Double-cell numbers occupy two stack positions, with the
    361 most-significant part on top.  Items on either stack may be addresses or
    362 data items of various kinds.  Stacks are of indefinite size, and usually
    363 grow towards low memory.
    364 
    365 <P>
    366 
    367 Although the structure of both stacks is the same, they have very
    368 different uses.  The user interacts most directly with the Data Stack,
    369 which contains arguments passed between words.  This function replaces
    370 the calling sequences used by conventional languages.  It is efficient
    371 internally, and makes routines intrinsically re-entrant.  The second
    372 stack is called the Return Stack, as its main function is to hold return
    373 addresses for nested definitions, although other kinds of data are
    374 sometimes kept there temporarily.
    375 
    376 <P>
    377 
    378 The use of the Data Stack (often called just <B>the stack</B>) leads to
    379 a notation in which operands precede operators.  The word 
    380 <a href=dpans6.htm#6.1.0695>ACCEPT</a> 
    381 in the
    382 example above took an address and count from the stack and left another
    383 address there.  Similarly, a word called 
    384 <a href=dpans17.htm#17.6.1.0780>BLANK</a> 
    385 expects an address and
    386 count, and will place the specified number of space characters (20H) in
    387 the region starting at that address.  Thus,
    388 
    389 
    390 <PRE>
    391 	PAD 25 BLANK
    392 </PRE>
    393 
    394 <P>
    395 
    396 will fill the scratch region whose address is pushed on the stack by 
    397 <a href=dpans6.htm#6.2.2000>PAD</a>
    398 with 25 spaces.  Application words are usually defined to work
    399 similarly.  For example,
    400 
    401 
    402 <PRE>
    403 	100 SAMPLES
    404 </PRE>
    405 
    406 <P>
    407 
    408 might be
    409 defined to record 100 measurements in a data array.
    410 
    411 <P>
    412 
    413 Arithmetic operators also expect values and leave results on the stack.
    414 For example, 
    415 <a href=dpans6.htm#6.1.0120>+</a> 
    416 adds the top two numbers on the stack, replacing them
    417 both by their sum.  Since results of operations are left on the stack,
    418 operations may be strung together without a need to define variables to
    419 use for temporary storage.
    420 
    421 <P>
    422 
    423 
    424 <hr>
    425 <A name=C.5.3>
    426 <H3>C.5.3 Interpreters</H3>
    427 </a>
    428 
    429 Forth is traditionally an interpretive system, in that program execution
    430 is controlled by data items rather than machine code.  Interpreters can
    431 be slow, but Forth maintains the high speed required of real-time
    432 applications by having two levels of interpretation.
    433 
    434 <P>
    435 
    436 The first is the text interpreter, which parses strings from the
    437 terminal or mass storage and looks each word up in the dictionary.  When
    438 a word is found it is executed by invoking the second level, the address
    439 interpreter.
    440 
    441 <P>
    442 
    443 The second is an <B>address interpreter</B>.  Although not all Forth
    444 systems are implemented in this way, it was the first and is still the
    445 primary implementation technology.  For a small cost in performance, an
    446 address interpreter can yield a very compact object program, which has
    447 been a major factor in Forth's wide acceptance in embedded systems and
    448 other applications where small object size is desirable.
    449 
    450 <P>
    451 
    452 The address interpreter processes strings of addresses or tokens
    453 compiled in definitions created by : 
    454 (<a href=dpans6.htm#6.1.0450>colon</a>), 
    455 by executing the
    456 definition pointed to by each.  The content of most definitions is a
    457 sequence of addresses of previously defined words, which will be
    458 executed by the address interpreter in turn.  Thus, when the word
    459 RECEIVE (defined above) is executed, the word 
    460 <a href=dpans6.htm#6.2.2000>PAD</a>, 
    461 the word 
    462 <a href=dpans6.htm#6.1.1290>DUP</a>, the
    463 literal 32, and the word 
    464 <a href=dpans6.htm#6.1.0695>ACCEPT</a> 
    465 will be executed in sequence.  The
    466 process is terminated by the 
    467 semicolon.  This execution requires no
    468 dictionary searches, parsing, or other logic, because when RECEIVE was
    469 compiled the dictionary was searched for each word, and its address (or
    470 other token) was placed in the next successive cell of the entry.  The
    471 text was not stored in memory, not even in condensed form.
    472 
    473 <P>
    474 
    475 The address interpreter has two important properties.  First, it is
    476 fast.  Although the actual speed depends upon the specific
    477 implementation, professional implementations are highly optimized, often
    478 requiring only one or two machine instructions per address.  On most
    479 benchmarks, a good Forth implementation substantially out-performs
    480 interpretive languages such as BASIC or LISP, and will compare favorably
    481 with other compiled high-level languages.
    482 
    483 <P>
    484 
    485 Second, the address interpreter makes Forth definitions extremely
    486 compact, as each reference requires only one cell.  In comparison, a
    487 subroutine call constructed by most compilers involves instructions for
    488 handling the calling sequence (unnecessary in Forth because of the
    489 stack) before and after a CALL or JSR instruction and address.
    490 
    491 <P>
    492 
    493 Most of the words in a Forth dictionary will be defined by : (colon) and
    494 interpreted by the address interpreter.  Most of Forth itself is defined
    495 this way.
    496 
    497 <P>
    498 
    499 
    500 <hr>
    501 <A name=C.5.4>
    502 <H3>C.5.4 Assembler</H3>
    503 </a>
    504 
    505 Most implementations of Forth include a macro assembler for the CPU on
    506 which they run.  By using the defining word 
    507 <a href=dpans15.htm#15.6.2.0930>CODE</a> 
    508 the programmer can
    509 create a definition whose behavior will consist of executing actual
    510 machine instructions.  CODE definitions may be used to do I/O, implement
    511 arithmetic primitives, and do other machine-dependent or time-critical
    512 processing.  When using CODE the programmer has full control over the
    513 CPU, as with any other assembler, and CODE definitions run at full
    514 machine speed.
    515 
    516 <P>
    517 
    518 This is an important feature of Forth.  It permits explicit
    519 computer-dependent code in manageable pieces with specific interfacing
    520 conventions that are machine-independent.  To move an application to a
    521 different processor requires re-coding only the CODE words, which will
    522 interact with other Forth words in exactly the same manner.
    523 
    524 <P>
    525 
    526 Forth assemblers are so compact (typically a few Kbytes) that they can
    527 be resident in the system (as are the compiler, editor, and other
    528 programming tools).  This means that the programmer can type in short
    529 CODE definitions and execute them immediately.  This capability is
    530 especially valuable in testing custom hardware.
    531 
    532 <P>
    533 
    534 
    535 <hr>
    536 <A name=C.5.5>
    537 <H3>C.5.5 Virtual memory</H3>
    538 </a>
    539 
    540 The final unique element of Forth is its way of using disk or other mass
    541 storage as a form of <B>virtual memory</B> for data and program source.
    542 As in the case of the address interpreter, this approach is historically
    543 characteristic of Forth, but is by no means universal.  Disk is divided
    544 into 1024-byte blocks.  Two or more buffers are provided in memory, into
    545 which blocks are read automatically when referred to.  Each block has a
    546 fixed block number, which in native systems is a direct function of its
    547 physical location.  If a block is changed in memory, it will be
    548 automatically written out when its buffer must be reused.  Explicit
    549 reads and writes are not needed; the program will find the data in
    550 memory whenever it accesses it.
    551 
    552 <P>
    553 
    554 Block-oriented disk handling is efficient and easy for native Forth
    555 systems to implement.  As a result, blocks provide a completely
    556 transportable mechanism for handling program source and data across both
    557 native and co-resident versions of Forth on different host operating
    558 systems.
    559 
    560 <P>
    561 
    562 Definitions in program source blocks are compiled into memory by the
    563 word 
    564 <a href=dpans7.htm#7.6.1.1790>LOAD</a>.  
    565 Most implementations include an editor, which formats a
    566 block for display into 16 lines of 64 characters each, and provides
    567 commands modifying the source.  An example of a Forth source block is
    568 given in Fig.  C.1 below.
    569 
    570 <P>
    571 
    572 Source blocks have historically been an important element in Forth
    573 style.  Just as Forth definitions may be considered the linguistic
    574 equivalent of sentences in natural languages, a block is analogous to a
    575 paragraph.  A block normally contains definitions related to a common
    576 theme, such as <B>vector arithmetic</B>.  A comment on the top line of
    577 the block identifies this theme.  An application may selectively load
    578 the blocks it needs.
    579 
    580 <P>
    581 
    582 Blocks are also used to store data.  Small records can be combined into
    583 a block, or large records spread over several blocks.  The programmer
    584 may allocate blocks in whatever way suits the application, and on native
    585 systems can increase performance by organizing data to minimize disk
    586 head motion.  Several Forth vendors have developed sophisticated file
    587 and data base systems based on Forth blocks.
    588 
    589 <P>
    590 
    591 Versions of Forth that run co-resident with a host OS often implement
    592 blocks in host OS files.  Others use the host files exclusively.  The
    593 Standard requires that blocks be available on systems providing any disk
    594 access method, as they are the only means of referencing disk that can
    595 be transportable across both native and co-resident implementations.
    596 
    597 <P>
    598 
    599 <hr>
    600 <a name=C.5.6>
    601 <H3>C.5.6 Programming environment</H3>
    602 </a>
    603 
    604 Although this Standard does not require it, most Forth systems include a
    605 resident editor.  This enables a programmer to edit source and recompile
    606 it into executable form without leaving the Forth environment.  As it is
    607 easy to organize an application into layers, it is often possible to
    608 recompile only the topmost layer (which is usually the one currently
    609 under development), a process which rarely takes more than a few
    610 seconds.
    611 
    612 <P>
    613 
    614 Most Forth systems also provide resident interactive debugging aids, not
    615 only including words such as those in 
    616 <a href=dpans15.htm>15.</a> The optional
    617 Programming-Tools word set, but also having the ability to examine and
    618 change the contents of 
    619 <a href=dpans6.htm#6.1.2410>VARIABLE</a>s 
    620 and other data items and to execute
    621 from the keyboard most of the component words in both the underlying
    622 Forth system and the application under development.
    623 
    624 <P>
    625 
    626 The combination of resident editor, integrated debugging tools, and
    627 direct executability of most defined words leads to a very interactive
    628 programming style, which has been shown to shorten development time.
    629 
    630 <P>
    631 
    632 
    633 <hr>
    634 <A name=C.5.7>
    635 <H3>C.5.7 Advanced programming features</H3>
    636 </a>
    637 
    638 One of the unusual characteristics of Forth is that the words the
    639 programmer defines in building an application become integral elements
    640 of the language itself, adding more and more powerful
    641 application-oriented features.
    642 
    643 <P>
    644 
    645 For example, Forth includes the words 
    646 <a href=dpans6.htm#6.1.2410>VARIABLE</a> and 
    647 <a href=dpans8.htm#8.6.1.0440>2VARIABLE</a> to name
    648 locations in which data may be stored, as well as 
    649 <a href=dpans6.htm#6.1.0950>CONSTANT</a> and 
    650 <a href=dpans8.htm#8.6.1.0360>2CONSTANT</a>
    651 to name single and double-cell values.  Suppose a programmer finds that
    652 an application needs arrays that would be automatically indexed through
    653 a number of two-cell items.  Such an array might be called 2ARRAY.  The
    654 prefix <B>2</B> in the name indicates that each element in this array
    655 will occupy two cells (as would the contents of a 2VARIABLE or
    656 2CONSTANT).  The prefix <B>2</B>, however, has significance only to a
    657 human and is no more significant to the text interpreter than any other
    658 character that may be used in a definition name.
    659 
    660 <P>
    661 
    662 Such a definition has two parts, as there are two <B>behaviors</B>
    663 associated with this new word 2ARRAY, one at compile time, and one at
    664 run or execute time.  These are best understood if we look at how 2ARRAY
    665 is used to define its arrays, and then how the array might be used in an
    666 application.  In fact, this is how one would design and implement this
    667 word.
    668 
    669 <P>
    670 
    671 Beginning the top-down design process, here's how we would like to use
    672 2ARRAY:
    673 
    674 
    675 <PRE>
    676 	100 2ARRAY RAW   50 2ARRAY REFINED
    677 </PRE>
    678 
    679 <P>
    680 
    681 In the first case, we are defining an array 100 elements long, whose
    682 name is RAW.  In the second, the array is 50 elements long, and is named
    683 REFINED.  In each case, a size parameter is supplied to 2ARRAY on the
    684 data stack (Forth's text interpreter automatically puts numbers there
    685 when it encounters them), and the name of the word immediately follows.
    686 This order is typical of Forth defining words.
    687 
    688 <P>
    689 
    690 When we use RAW or REFINED, we would like to supply on the stack the
    691 index of the element we want, and get back the address of that element
    692 on the stack.  Such a reference would characteristically take place in a
    693 loop.  Here's a representative loop that accepts a two-cell value from a
    694 hypothetical application word DATA and stores it in the next element of
    695 RAW:
    696 
    697 
    698 <PRE>
    699 	: ACQUIRE 100 0 DO DATA I RAW 2! LOOP ;
    700 </PRE>
    701 
    702 <P>
    703 
    704 The name of this definition is ACQUIRE.  The loop begins with 
    705 <a href=dpans6.htm#6.1.1240>DO</a>, ends
    706 with 
    707 <a href=dpans6.htm#6.1.1800>LOOP</a>, 
    708 and will execute with index values running from 0 through 99.
    709 Within the loop, DATA gets a value.  The word 
    710 <a href=dpans6.htm#6.1.1680>I</a> 
    711 returns the current
    712 value of the loop index, which is the argument to RAW.  The address of
    713 the selected element, returned by RAW, and the value, which has remained
    714 on the stack since DATA, are passed to the word 
    715 <a href=dpans6.htm#6.1.0310>2!</a> 
    716 (pronounced
    717 <B>two-store</B>), which stores two stack items in the address.
    718 
    719 <P>
    720 
    721 Now that we have specified exactly what 2ARRAY does and how the words it
    722 defines are to behave, we are ready to write the two parts of its
    723 definition:
    724 <P>
    725 
    726 
    727 <PRE>
    728 	: 2ARRAY  ( n -- )
    729 	   CREATE  2* CELLS ALLOT
    730 	   DOES>  ( i a -- a')  SWAP  2*
    731 	CELLS + ;
    732 </PRE>
    733 
    734 <P>
    735 
    736 The part of the definition before the word 
    737 <a href=dpans6.htm#6.1.1250>DOES></a> 
    738 specifies the
    739 <B>compile-time</B> behavior, that is, what the 2ARRAY will do when it
    740 us used to define a word such as RAW.  The comment indicates that this
    741 part expects a number on the stack, which is the size parameter.  The
    742 word 
    743 <a href=dpans6.htm#6.1.1000>CREATE</a> 
    744 constructs the definition for the new word.  The phrase 
    745 <a href=dpans6.htm#6.1.0320>2*</a>
    746 <a href=dpans6.htm#6.1.0890>CELLS</a> 
    747 converts the size parameter from two-cell units to the internal
    748 addressing units of the system (normally characters).  
    749 <a href=dpans6.htm#6.1.0710>ALLOT</a> 
    750 then
    751 allocates the specified amount of memory to contain the data to be
    752 associated with the newly defined array.
    753 
    754 <P>
    755 
    756 The second line defines the <B>run-time</B> behavior that will be shared
    757 by all words defined by 2ARRAY, such as RAW and REFINED.  The word DOES>
    758 terminates the first part of the definition and begins the second part.
    759 A second comment here indicates that this code expects an index and an
    760 address on the stack, and will return a different address.  The index is
    761 supplied on the stack by the caller (of RAW in the example), while the
    762 address of the content of a word defined in this way (the ALLOTted
    763 region) is automatically pushed on top of the stack before this section
    764 of the code is to be executed.  This code works as follows: 
    765 <a href=dpans6.htm#6.1.2260>SWAP</a>
    766 reverses the order of the two stack items, to get the index on top.  2*
    767 CELLS converts the index to the internal addressing units as in the
    768 compile-time section, to yield an offset from the beginning of the
    769 array.  The word 
    770 <a href=dpans6.htm#6.1.0120>+</a> 
    771 then adds the offset to the address of the start of
    772 the array to give the effective address, which is the desired result.
    773 
    774 <P>
    775 
    776 Given this basic definition, one could easily modify it to do more
    777 sophisticated things.  For example, the compile-time code could be
    778 changed to initialize the array to zeros, spaces, or any other desired
    779 initial value.  The size of the array could be compiled at its
    780 beginning, so that the run-time code could compare the index against it
    781 to ensure it is within range, or the entire array could be made to
    782 reside on disk instead of main memory.  None of these changes would
    783 affect the run-time usage we have specified in any way.  This
    784 illustrates a little of the flexibility available with these defining
    785 words.
    786 
    787 <P>
    788 
    789 
    790 <hr>
    791 <A name=C.5.8>
    792 <H3>C.5.8 A programming example</H3>
    793 </a>
    794 
    795 <a href=dpansc.htm#Figure.C.1>Figure C.1</a>
    796 contains a typical block of Forth source.  It represents a
    797 portion of an application that controls a bank of eight LEDs used as
    798 indicator lamps on an instrument, and indicates some of the ways in
    799 which Forth definitions of various kinds combine in an application
    800 environment.  This example was coded for a STD-bus system with an 8088
    801 processor and a millisecond clock, which is also used in the example.
    802 
    803 <P>
    804 
    805 The LEDs are interfaced through a single 8-bit port whose address is
    806 40H.  This location is defined as a 
    807 <a href=dpans6.htm#6.1.0950>CONSTANT</a> 
    808 on Line 1, so that it may
    809 be referred to by name; should the address change, one need only adjust
    810 the value of this constant.  The word LIGHTS returns this address on the
    811 stack.  The definition LIGHT takes a value on the stack and sends it to
    812 the device.  The nature of this value is a bit mask, whose bits
    813 correspond directly to the individual lights.
    814 
    815 <P>
    816 
    817 Thus, the command 255 LIGHT will turn on all lights, while 0 LIGHT will
    818 turn them all off.
    819 
    820 <P>
    821 
    822 <a name=Figure.C.1>*</a>
    823 <PRE>
    824 Block 180
    825   0.      ( LED control )
    826   1.      HEX 40 CONSTANT LIGHTS DECIMAL
    827   2. : LIGHT ( n -- )  LIGHTS OUTPUT ;
    828   3.
    829   4. VARIABLE DELAY
    830   5. : SLOW  500 DELAY ! ;
    831   6. : FAST  100 DELAY ! ;
    832   7. : COUNTS 256 0 DO I LIGHT DELAY @ MS  LOOP ;
    833   8.
    834   9. : LAMP ( n -  )  CREATE ,  DOES> ( a -- n )   @ ;
    835  10. 1 LAMP POWER       2 LAMP HV     4 LAMP TORCH
    836  11. 8 LAMP SAMPLING   16 LAMP IDLING
    837  12.
    838  13. VARIABLE LAMPS
    839  14. : TOGGLE ( n -- ) LAMPS @ XOR DUP LAMPS ! LIGHT ;
    840  15.
    841 </PRE>
    842 <P>
    843 
    844 Figure C.1 - Forth source block containing words that control a set of LEDs.
    845 
    846 <P>
    847 
    848 Lines 4 - 7 contain a simple diagnostic of the sort one might type in
    849 from the terminal to confirm that everything is working.  The variable
    850 DELAY contains a delay time in milliseconds - execution of the word
    851 DELAY returns the address of this variable.  Two values of DELAY are set
    852 by the definitions SLOW and FAST, using the Forth operator 
    853 <a href=dpans6.htm#6.1.0010>!</a> 
    854 (pronounced
    855 <B>store</B>) which takes a value and an address, and stores the value
    856 in the address.  The definition COUNTS runs a loop from 0 through 255
    857 (Forth loops of this type are exclusive at the upper end of the range),
    858 sending each value to the lights and then waiting for the period
    859 specified by DELAY.  The word 
    860 <a href=dpans6.htm#6.1.0650>@</a> 
    861 (pronounced <B>fetch</B>) fetches a
    862 value from an address, in this case the address supplied by DELAY.  This
    863 value is passed to 
    864 <a href=dpans10.htm#10.6.2.1905>MS</a>, 
    865 which waits the specified number of milliseconds.
    866 The result of executing COUNTS is that the lights will count from 0 to
    867 255 at the desired rate.  To run this, one would type:
    868 
    869 
    870 <PRE>
    871 	SLOW COUNTS   or   FAST COUNTS
    872 </PRE>
    873 
    874 <P>
    875 
    876 at the terminal.
    877 
    878 <P>
    879 
    880 Line 9 provides the capability of naming individual lamps.  In this
    881 application they are being used as indicator lights.  The word LAMP is a
    882 defining word which takes as an argument a mask which represents a
    883 particular lamp, and compiles it as a named entity.  Lines 10 and 11
    884 contain five uses of LAMP to name particular indicators.  When one of
    885 these words such as POWER is executed, the mask is returned on the
    886 stack.  In fact, the behavior of defining a value such that when the
    887 word is invoked the value is returned, is identical to the behavior of a
    888 Forth CONSTANT.  We created a new defining word here, however, to
    889 illustrate how this would be done.
    890 
    891 <P>
    892 
    893 Finally, on lines 13 and 14, we have the words that will control the
    894 light panel.  LAMPS is a variable that contains the current state of the
    895 lamps.  The word TOGGLE takes a mask (which might be supplied by one of
    896 the LAMP words) and changes the state of that particular lamp, saving
    897 the result in LAMPS.
    898 
    899 <P>
    900 
    901 In the remainder of the application, the lamp names and TOGGLE are
    902 probably the only words that will be executed directly.  The usage there
    903 will be, for example:
    904 
    905 
    906 <PRE>
    907 	POWER TOGGLE   or   SAMPLING TOGGLE
    908 </PRE>
    909 
    910 <P>
    911 
    912 as appropriate, whenever the system indicators need to be changed.
    913 
    914 <P>
    915 
    916 The time to compile this block of code on that system was about half a
    917 second, including the time to fetch it from disk.  So it is quite
    918 practical (and normal practice) for a programmer to simply type in a
    919 definition and try it immediately.
    920 
    921 <P>
    922 
    923 In addition, one always has the capability of communicating with
    924 external devices directly.  The first thing one would do when told about
    925 the lamps would be to type:
    926 
    927 
    928 <PRE>
    929 	HEX FF 40 OUTPUT
    930 </PRE>
    931 
    932 <P>
    933 
    934 and see if all the lamps come on.  If not, the presumption is that
    935 something is amiss with the hardware, since this phrase directly
    936 transmits the <B>all ones</B> mask to the device.  This type of direct
    937 interaction is useful in applications involving custom hardware, as it
    938 reduces hardware debugging time.
    939 
    940 <P>
    941 
    942 
    943 <hr>
    944 <A name=C.6>
    945 <H2>C.6 Multiprogrammed systems</H2>
    946 </a>
    947 
    948 Multiprogrammed Forth systems have existed since about 1970.  The
    949 earliest public Forth systems propagated the <B>hooks</B> for this
    950 capability despite the fact that many did not use them.  Nevertheless
    951 the underlying assumptions have been common knowledge in the community,
    952 and there exists considerable common ground among these multiprogrammed
    953 systems.  These systems are not just language processors, but contain
    954 operating system characteristics as well.  Many of these integrated
    955 systems run entirely stand-alone, performing all necessary operating
    956 system functions.
    957 
    958 <P>
    959 
    960 Some Forth systems are very fast, and can support both multi-tasking and
    961 multi-user operation even on computers whose hardware is usually thought
    962 incapable of such advanced operation.  For example, one producer of
    963 telephone switchboards is running over 50 tasks on a Z80.  There are
    964 several multiprogrammed products for PC's, some of which even support
    965 multiple users.  Even on computers that are commonly used in multi-user
    966 operations, the number of users that can be supported may be much larger
    967 than expected.  One large data-base application running on a single
    968 68000 has over 100 terminals updating and querying its data-base, with
    969 no significant degradation.
    970 
    971 <P>
    972 
    973 Multi-user systems may also support multiple programmers, each of which
    974 has a private dictionary, stacks, and a set of variables controlling
    975 that task.  The private dictionary is linked to a shared, re-entrant
    976 dictionary containing all the standard Forth functions.  The private
    977 dictionary can be used to develop application code which may later be
    978 integrated into the shared dictionary.  It may also be used to perform
    979 functions requiring text interpretation, including compilation and
    980 execution of source code.
    981 
    982 <P>
    983 
    984 <hr>
    985 <A name=C.7>
    986 <H2>C.7 Design and management considerations</H2>
    987 </a>
    988 
    989 Just as the choice of building materials has a strong effect on the
    990 design and construction of a building, the choice of language and
    991 operating system will affect both application design and project
    992 management decisions.
    993 
    994 <P>
    995 
    996 Conventionally, software projects progress through four stages:
    997 analysis, design, coding, and testing.  A Forth project necessarily
    998 incorporates these activities as well.  Forth is optimized for a
    999 project-management methodology featuring small teams of skilled
   1000 professionals.  Forth encourages an iterative process of <B>successive
   1001 prototyping</B> wherein high-level Forth is used as an executable design
   1002 tool, with <B>stubs</B> replacing lower-level routines as necessary
   1003 (e.g., for hardware that isn't built yet).
   1004 
   1005 <P>
   1006 
   1007 In many cases successive prototyping can produce a sounder, more useful
   1008 product.  As the project progresses, implementors learn things that
   1009 could lead to a better design.  Wiser decisions can be made if true
   1010 relative costs are known, and often this isn't possible until prototype
   1011 code can be written and tried.
   1012 
   1013 <P>
   1014 
   1015 Using Forth can shorten the time required for software development, and
   1016 reduce the level of effort required for maintenance and modifications
   1017 during the life of the product as well.
   1018 
   1019 <P>
   1020 
   1021 
   1022 <hr>
   1023 <A name=C.8>
   1024 <H2>C.8 Conclusion</H2>
   1025 </a>
   1026 
   1027 Forth has produced some remarkable achievements in a variety of
   1028 application areas.  In the last few years its acceptance has grown
   1029 rapidly, particularly among programmers looking for ways to improve
   1030 their productivity and managers looking for ways to simplify new
   1031 software-development projects.
   1032 
   1033 <P>
   1034 
   1035 
   1036 
   1037 <hr>
   1038 <A href=dpans.htm#toc><IMG   src="up.gif" ></A>    Table of Contents 
   1039 <BR>
   1040 <A href=dpansd.htm><IMG   src="right.gif" ></A>
   1041 Next Section
   1042 <P>
   1043 </BODY>
   1044 </HTML>