home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1588 < prev    next >
Internet Message Format  |  1990-12-28  |  15KB

  1. From: mip@IDA.LiU.SE (Mikael Patel)
  2. Newsgroups: alt.sources
  3. Subject: TILE Forth Release 2.0 (repost)
  4. Message-ID: <1956@majestix.ida.liu.se>
  5. Date: 16 Jul 90 18:48:07 GMT
  6.  
  7.  
  8. THREADED INTERPRETIVE LANGUAGE ENVIRONMENT (TILE) [RELEASE 2.0]
  9.  
  10. June 29, 1990
  11.  
  12. Mikael R.K. Patel
  13. Computer Aided Design Laboratory (CADLAB)
  14. Department of Computer and Information Science
  15. Linkoping University
  16. S-581 83 LINKOPING
  17. SWEDEN
  18. Email: mip@ida.liu.se
  19.  
  20.  
  21. 1.    INTRODUCTION
  22.  
  23. TILE Forth is a 32-bit implementation of the Forth-83 Standard 
  24. written in C. Thus allowing it to be easily moved between different 
  25. computers compared to traditional Forth implementations in assembly.
  26.  
  27. Most Forth implementations are done in assembly to be able to
  28. utilize the underlying architecture as optimal as possible. TILE 
  29. Forth goes another direction. The main idea behind TILE Forth is to 
  30. achieve a portable forth implementation for workstations and medium 
  31. size computer systems so that new groups of programmers may be exposed 
  32. to the flavor of an extensible language such as Forth. 
  33.  
  34. The implementation of TILE Forth is selected so that, in principle, 
  35. any C-level procedure may become available on the interactive and
  36. incremental forth level. Other models of implementation of a threaded
  37. interpreter in C are possible but are not as flexible.
  38.  
  39. TILE Forth is organized as a set of modules to allow the kernel to be 
  40. used as a general threading engine for C. Environment dependencies such
  41. as memory allocation, error handling and input/output have been separated
  42. out of the kernel to increase flexibility. The forth application is "just"
  43. an example of how to use the kernel.
  44.  
  45. Comparing forth implementation using the traditional benchmark such as
  46. the classical sieves calculation is difficult because of difference in
  47. speed between workstations and personal computers. The Byte sieves
  48. benchmark is reported to typically run in 16 seconds on a direct threaded
  49. forth implementation. This benchmark will run in 27 seconds in TILE forth 
  50. on a SUN-3/60 and less than 13 seconds on a SUN SPARCstation 1. These times 
  51. are the total time for loading TILE forth, compiling and executing the
  52. benchmark. Comparing to, for instance, other interpretive languages such 
  53. as Lisp, where one of the classical benchmarks is calculation of the 
  54. Fibonacci function, the performance increase is over one magnitude.
  55.  
  56. The kernel supports the Standard Forth-83 word set except for the
  57. blocks file word set which are not used. The kernel is extended with
  58. many of the concepts from modern programming languages. Here is a list
  59. of some of the extensions; argument binding and local variables, queue
  60. management, low level compiler words, string functions, floating point
  61. numbers, exceptions and multi-tasking. The TILE Forth environment also
  62. contains a set of reusable source files for high level multi-tasking, 
  63. data modeling and structuring modules, and a number of programming tools.
  64.  
  65. To allow interaction and incremental program development TILE Forth
  66. includes a programming environment as a mode in GNU Emacs. This environ-
  67. ment helps with program structuring, documentation search, and program
  68. development. Each vocabulary in the kernel and the source library file is 
  69. described by a manual, documentation and test file. This style of 
  70. programming is emphasized throughout the environment to increase 
  71. understanding and reusability of the library modules. During compilation
  72. TILE Forth's io-package keeps track for which modules have been loaded
  73. so that they are only loaded once even if included by several modules.
  74.  
  75. Writing a Forth in C gives some possibilities that normally are
  76. not available when performing the same task in assembly. TILE Forth
  77. has been profiled using the available tools under Unix. This information
  78. has been used to optimize the compiler so that it achieves a compilation
  79. speed of over 200.000 lines per minute on my machine (a disk-less SUN
  80. SPARCstation 1). Currently code is only saved in source form and 
  81. applications are typically "compile-and-go".
  82.  
  83. So far TILE Forth has been ported and tested at over forty locations
  84. without any major problems except where C compilers do not allow sub-
  85. routine pointers in data structures. 
  86.  
  87.  
  88. 2.    EXTENSIONS
  89.  
  90. What is new in the TILE forth? First of all the overall organization
  91. of words. To increase portability and understanding of forth code modules
  92. vocabularies are used as the primary packaging mechanism. New data types
  93. such as rational and floating point numbers are implemented in separate
  94. vocabularies. The vocabularies act as both a program module and an 
  95. abstract data type.
  96.  
  97. 2.1    Extendable interpreter
  98.  
  99. To allow extension of the literal symbol set (normally only integer
  100. numbers) each vocabulary is allowed to have a literal recognition
  101. function. This function is executed by the interpreter when the symbol
  102. search has failed. The literal recognizer for the forth vocabulary is 
  103. "?number". This simple mechanism allows modules such as for rational and 
  104. floating point numbers, and integer ranges to extend with their own
  105. literal function.
  106.  
  107. 2.2    Data description
  108.  
  109. As the Forth-83 Standard lack tools for description of data structures 
  110. TILE Forth contains a fairly large library of tools for this purpose. 
  111. These are described more in detail in the next section.
  112.  
  113. 2.3    Argument binding and local variables
  114.  
  115. When writing a forth function with many arguments stack shuffling
  116. becomes a real pain. Argument binding and local variables is a nice
  117. way out of these situations. Also for the new-comer to Forth this
  118. gives some support to this at first very cryptic language. Even
  119. the stack function may be rewritten using this mechanism:
  120.  
  121.     : 2drop { a b } ;
  122.     : 2swap { a b c d } c d a b  ;
  123.     : fac { n } n 0> if n 1- recurse n * else 1 then ;
  124.  
  125. The argument frame is created on top of the parameter stack and is
  126. disposed when functions is exited. This implementations style of
  127. reduces the cost of binding as most functions have more arguments
  128. then return values. A minimum number of data elements have to be
  129. move to create and manage the argument frame.
  130.  
  131. 2.4     Exception handling
  132.  
  133. Another extension in TILE Forth is exception handling with multiple
  134. exception handling code block. The syntactical structure is very
  135. close to that of Ada, i.e., any colon definition may contain an error
  136. handling section. Should an error occur during the execution of the
  137. function the stack status is restore to the situation at the call
  138. of the function and the lastest exception block is executed with the 
  139. signal or exception as a parameter;
  140.  
  141.     exception zero-divide ( -- exception)
  142.  
  143.     : div ( x y -- z)
  144.           /
  145.     exception> ( x y signal -- )
  146.       drop zero-divide raise
  147.         ;
  148.  
  149. Error situations may be indicated using an exception raise function. 
  150. Low level errors, such as zero division, are transformed to exceptions 
  151. in TILE Forth.
  152.  
  153. 2.5    Entry visibility and forward declaration
  154.  
  155. Last, some of the less significant extension are forward declaration
  156. of entries, hidden or private entries, and extra entry modes. Forward
  157. declaration of entries are automatically bound when the entry is later
  158. given a definition. Should a binding not exist at run-time an error
  159. message is given and the computation is aborted.
  160.  
  161.     forward eval ( ... )
  162.  
  163.     : apply ( ... ) ... eval ... ;
  164.     : eval ( ... ) ... apply ... ;
  165.  
  166. Three new entry modes have been added to the classical forth model 
  167. (immediate). These allow hiding of entries in different situations.
  168. The first two marks the last defined word's visibility according to
  169. an interpreter state. These two modifiers are called "compilation" 
  170. and "execution" and are used as "immediate". A word like "if" is
  171. "compilation immediate" meaning it is visible when compiling and 
  172. then always executed. 
  173.  
  174.     compiler forth definitions
  175.  
  176.     : if ( -- ) compile (?branch) >mark ; compilation immediate
  177.  
  178. The "private" modifier is somewhat different. It concerns the
  179. visibility across vocabularies (modules and types). If a word is
  180. marked as "private" the word is only visible when the vocabulary in 
  181. which it is defined in is "current". This is very close to the concept
  182. of hidden in modules and packages in Modula-2 and Ada.
  183.  
  184.     4 field +name ( entry -- ptr) private
  185.  
  186. The above definition will only be visible in the vocabulary it was 
  187. defined. The "private" modifier is useful to help isolate implementation
  188. dependencies and reduce the name space which also increases compilation
  189. speed.
  190.  
  191.  
  192. 3.     SOURCE LIBRARY
  193.  
  194. The TILE Forth programming environment contains a number of tools to 
  195. make programming in Forth a bit easier. If you have GNU Emacs, TILE 
  196. Forth may run in a specialized forth-mode. This mode supports automatic 
  197. program indentation (pretty printing), documentation search, and 
  198. interactive and incremental program development, or "edit-compile-test" 
  199. style of program development.
  200.  
  201. To aid program development there is also a source code library with
  202. manual pages, documentation (glossary), and test and example code.
  203. Most of the source code are data modeling tools. In principle, from 
  204. bit field definition to object oriented structures are available. The 
  205. source code library also contains debugging tools for tracing, break-
  206. point'ing and profiling of programs. 
  207.  
  208. The first level of data modeling tools are modules for describing;
  209. 1) bit fields, 2) structures (records), 3) aggregates of data 
  210. (vectors, stacks, buffers, etc), and 4) high level data objects
  211. (lists, sets, etc).
  212.  
  213. The next level of tools are some tools for high level syntactic sugar
  214. for multi-tasking concepts (semaphores, channels, etc), finite state
  215. machines (FSM), anonymous code block (blocks), a general top down parser
  216. with backtrack and semantic binding, and a simulation package. The source
  217. library will be extended during the coming releases.
  218.  
  219.  
  220. 4.     PROGRAMMING STYLE
  221.  
  222. A source code module has, in general, the following structure; the 
  223. first section includes any modules needed (these are only loaded once).
  224. Second follows global definitions for the module. Normally this is 
  225. a vocabulary for the module. Third comes the search chain to be used
  226. throughout the module. It is important not to change the search order
  227. as 1) it becomes difficult for a reader to understand the code, 2)
  228. any change in the search chain flushes the internal lookup cache
  229. in TILE Forth and reduces compilation speed.
  230.  
  231.     .( Loading the Library...) cr
  232.  
  233.     #include someLibrary.f83
  234.     ...
  235.  
  236.     ( Global data and definitions)
  237.  
  238.     : someGlobalDefinitions ( -- ) ... ;
  239.  
  240.     vocabulary theLibrary
  241.  
  242.     someLibrary ... theLibrary definitions
  243.  
  244.     ( Local data and definitions)
  245.  
  246.     : somePrivateDefinitions ( -- ) ... ; private
  247.     ...
  248.     : someDefinitions ( -- ) ... ; 
  249.  
  250.     forth only
  251.  
  252. To create lexical levels within the same vocabulary the word "restore" 
  253. may be used. It stores the vocabulary pointer to the given entry and 
  254. thus hides the words defined after this entry. The word "restore" has 
  255. much the same action as "forget" but without putting back the dictionary 
  256. pointer.
  257.  
  258.  
  259. 5.    SOURCE FILES
  260.  
  261. The TILE Forth source is broken down into the following files:
  262.  
  263. README
  264.    This short documentation of TILE.
  265.  
  266. COPYING
  267.    The GNU General Public License.
  268.  
  269. INSTALL
  270.    Some help on how to install TILE Forth.
  271.  
  272. PORTING
  273.    Some help on how to port TILE Forth and typical problems
  274.  
  275. Makefile
  276.    Allows a number of compilation styles for debugging, profiling, 
  277.    sharing etc. New machines and conditional compilation symbols are 
  278.    added here.
  279.  
  280. src
  281.   The C source library with the kernel code and GNU Emacs forth-mode.
  282.  
  283. lib
  284.    The Forth-83 source library for data description and management, 
  285.    high level tasking, etc.
  286.  
  287. tst
  288.    Test file for each Forth-83 source code file and a set of benchmarks.
  289.  
  290. man
  291.    Manual pages for the TILE Forth C kernel and Forth-83 source code 
  292.    library.
  293.  
  294. doc
  295.    Documentation and glossaries for each source code file and kernel
  296.    vocabularies.
  297.  
  298. bin
  299.    Utility commands and the TILE forth compiler/interpreter.
  300.  
  301.  
  302.  
  303. 6.    CONFIGURATION
  304.  
  305. TILE forth is targeted for 32-bit machines and no special aid is 
  306. available to allow it to be compiled for other bit-widths. The 
  307. configuration is maintained by a "make" files. 
  308.  
  309. This configuration file allows a number of different modes to support
  310. typical program development phases (on C level) such as debugging, 
  311. profiling, optimization and packaging. Please see the information in
  312. these files.
  313.  
  314.  
  315. 7.    COPYING
  316.  
  317. This software is offered as shareware. You may use it freely, but 
  318. if you do use it and find it useful, you are encouraged to send the
  319. author a contribution (>= $50) to the following address:
  320.  
  321.     TILE Technology HB
  322.     Stragatan 19
  323.     S-582 67 Linkoping
  324.     SWEDEN
  325.  
  326. If you send me a contribution, I will send you manual pages and 
  327. documentation files and will answer questions by mail. Also your
  328. name will be put on a distribution list for future releases.
  329.  
  330. For further information about copying see the file COPYING and
  331. the headers in the source code files. Commercial usage of the
  332. kernel is not allowed without a license from the company above.
  333.  
  334.  
  335. 8.    NOTE
  336.  
  337. Due to the 32-bit implementation in C a number of Forth-83 definitions 
  338. are not directly confirmed. Below is a short list of words that might 
  339. give problems when porting Forth code to this environment:
  340.  
  341. * The Block Word Set is not supported. Source code is saved as text 
  342.   files.
  343.  
  344. * All stacks and words size are 32-bit. Thus special care must be 
  345.   taken with memory allocation and access.
  346.  
  347. * Lowercase and uppercase are distinguished, and all forth words are
  348.   lowercase. 
  349.  
  350. * A word in TILE is allowed arbitrary length as the name is stored as
  351.   as a null terminated string.
  352.  
  353. * Input such as "key" performs a read operation to the operating system
  354.   thus will echo the characters.
  355.  
  356. * Variables should not allocate extra memory. "create" should be used.
  357.  
  358. * Double number arithmetic functions are not available.
  359.  
  360. Some major changes have been made to the kernel in this second release.
  361. To allow implementation of floating point numbers and increase porting
  362. the kernel is now written in its own extendable typing system. Some
  363. extension have been removed such as the casting operator in the 
  364. interpreter.
  365.  
  366.  
  367. ACKNOWLEDGMENTS
  368.  
  369. First of all I wish to express my gratitude to Goran Rydqvist for helped
  370. me out with the first version of the kernel and who implemented the 
  371. forth-mode for GNU Emacs. 
  372.  
  373. Second a special thanks to the beta test group who gave me valuable
  374. feedback. Especially Mitch Bradley, Bob Giovannucci Jr., Moises Lejter, 
  375. and Brooks David Smith. 
  376.  
  377. Last, I wish to thank the may users that have been in touch after the
  378. first release and given me many comments and encouragements.
  379.  
  380. Thank you all.
  381.