home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / oberon / oberon.doc < prev    next >
Text File  |  1991-06-17  |  7KB  |  221 lines
  1.  
  2. Oberon-M(tm) version 1.0    for Intel 80x86 processors running MSDOS
  3.  
  4. (c) Copyright E. R. Videki, 1989-1991,
  5.     ALL RIGHTS RESERVED
  6.         P. O. Box 58
  7.         Morgan Hill, California 95038
  8.         USA
  9.  
  10.         * Special Pre-Release Version*
  11.  
  12.  
  13.     Internet address (as of March 1991)
  14.         erv @ k2.everest.tandem.com
  15.         IP address 130.252.59.153
  16.  
  17.  
  18.  
  19.  
  20. This package is a complete Oberon compiler for the MSDOS
  21. environment.  The code generated is in standard MSDOS object
  22. files which will run on 80x86 processors under the common
  23. MSDOS derivatives.  Note that 8088 and 8086 processors
  24. are NOT supported.
  25.  
  26. No warrantees are expressed or implied.  The user of
  27. the contents of this package assumes full responsibility
  28. for its use, fitness for any purpose, and applications.
  29.  
  30.  
  31.  
  32. COMPILER
  33.  
  34.  
  35. The compiler itself is called "oc.exe".  It is run with the
  36. following command line under MSDOS:
  37.  
  38.         oc  filename[.mod]  [def]
  39.  
  40. If the optional ".mod" is ommitted, the compiler will append
  41. it to the file name.
  42.  
  43. The "def" option, specified just as shown, will cause a
  44. module which exports items to have a special symbol file
  45. written to disk.  This is a safety feature: modules are
  46. checked at run time for consistency of level of object form
  47. with the form used for compilation.  Only when you specify
  48. the "def" option after the file name will the symbol file
  49. used when compiling other modules which import this one
  50. be (re-)written on the disk.
  51.  
  52. If you are writing a module that is
  53. imported by others, when you want its symbol file to be
  54. (re-)written (and used by other compiliations), you MUST specify
  55. "def" on the command line of the module that is to be
  56. imported.  You do not use "def" when a module exports
  57. nothing (such as your "main" module).
  58.  
  59. The compiler generates standard MSDOS object files which
  60. ultimately must be linked with the other object files
  61. representing imported Oberon modules, plus
  62. linked with the special run-time support file SYS.OBJ  .
  63.  
  64.  
  65.  
  66. LINKING OBJECT FILES
  67.  
  68. A standard MSDOS linker or its equivalent will bind together
  69. the object files.  There are two rules that must be followed.
  70.  
  71.         1) Your "main" module (the one that is to receive
  72.            control from DOS after all other modules are
  73.            initialized, and which is not imported by any
  74.            other module) must be named FIRST in the list
  75.            of modules to link together.
  76.  
  77.         2) The small run-time support object file, named
  78.            SYS.OBJ must be named LAST in the list of modules
  79.            to link together.
  80.  
  81. An example of use:
  82.  
  83.         link  mymain+import1+import2+sys ;
  84.  
  85. ...will generate a file named "mymain.exe" which is
  86. executable (assuming your programming is correct!).
  87.  
  88.  
  89.  
  90. OTHER FILES SUPPLIED IN THIS PACKAGE
  91.  
  92.  
  93. The compiler is supplied with a number of additional files
  94. in this package.
  95.  
  96.  
  97.  
  98. Oberon Language Files:
  99.  
  100. obrept.ps       - Niklaus Wirth's definition of the Oberon
  101.                         language, which is supported by
  102.                         this Oberon-M(tm) compiler.
  103. obebnf.ps       - The EBNF summary of the language
  104.  
  105. *** Note: these files must be downloaded to a
  106. PostScript(tm) processing printer for correct formatting! ***
  107.  
  108.  
  109.  
  110. Oberon Modules for use under MSDOS
  111.  
  112. These are modules which work under most (if not all) versions
  113. of MSDOS, and which you may import into your own
  114. programs.  They are provided in source form, as well
  115. as "ready to link" form, plus pre-compiled symbol forms
  116. so that you do not have to compile them before importing
  117. them.
  118.  
  119. They include:
  120.  
  121.         Disk    Disk file direct-handling
  122.         IO      General I/O operations
  123.         LineIO  Specific line-oriented file I/O
  124.         LIO     A version of LineIO with indentation
  125.         Screen  Direct-writing to many display screen types
  126.         Parms   Reading parameters from the MSDOS command line
  127.         Term    I/O specifically for keyboard and display
  128.  
  129.  
  130.  
  131. Example Module
  132.  
  133. The module Abu.mod is a full-featured example of using
  134. the Oberon-M(tm) compiler with many of the supplied modules
  135. to make a simple fast-executing, very small, full-screen
  136. file browser.  (Note: Since this module uses the Screen.Mod
  137. module which may be incompatible with some types of display
  138. screens, you may have to modify Screen for your machine
  139. before Abu.mod works.)
  140.  
  141. If you want to execute this example before fiddling with
  142. the source, simply type:
  143.  
  144.         abu  <filename>
  145.  
  146. and the Abu.exe file will let you browse the file you named.
  147.  
  148.  
  149.  
  150. Utility Module
  151.  
  152. The executable file "xdef.exe" is a utility program that
  153. will scan your source modules and generate a file named
  154. with a ".dfn" file extension appended to the file name.
  155. This resultant file contains a summary of the exported
  156. objects from the file.  In other words, the xdef utility
  157. condenses an entire source module into only those items
  158. which are visible to clients (importers) of that module,
  159. and does not show the inner details.
  160.  
  161. To execute under MSDOS, type:
  162.  
  163.         xdef <filename>
  164.  
  165. and the result file will be generated silently.  Two
  166. important notes: 1) the source should be error-free
  167. before using xdef, else xdef may have problems;
  168. 2) if you forget to specify a file name, xdef halts
  169. with an error code.
  170.  
  171.  
  172. OBERON-M(tm) SPECIFICS
  173.  
  174. The Oberon-M compiler is source compatible with the
  175. Oberon language found under the Oberon System produced
  176. by the Swiss Federal Institute of Technology (where
  177. Niklaus Wirth is).  However, there are some specifics
  178. for the MSDOS environment you must keep in mind.
  179.  
  180.  
  181. * User Halt codes must be greater than 100.
  182.  
  183. * The SYSTEM module built-into the compiler is
  184.   for MSDOS, but is the same as is defined by
  185.   Niklaus Wirth in terms of exported objects.
  186.  
  187. * Running under DOS requires a "main" module
  188.   that does not import anything, and which must
  189.   be the first one named in the list of files
  190.   linked together.
  191.  
  192.  
  193.  
  194.  
  195. OTHER READING
  196.  
  197. You may find more information about Oberon in the
  198. following articles:
  199.  
  200. N. Wirth        "Type Extensions"
  201.         ACM Trans. on Prog. Languages and Systems
  202.         10,2 (April 1988) 204-214
  203.  
  204. N. Wirth        "From Modula to Oberon"
  205.         Software- Practice and Experience 18,7
  206.         (July 1988) 661-670
  207.  
  208. N. Wirth        "The Programming Language Oberon"
  209.         Software- Practice and Experience 18,7
  210.         (July 1988) 671-690
  211.     ***Note: the updated report of the language
  212.     is included with this package and supercedes
  213.     this report*****
  214.  
  215. N. Wirth and J. Gutknecht
  216.                 "The Oberon System"
  217.         Software- Practice and Experience 19
  218.         (September 1989) 857-893
  219.  
  220.  
  221.