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