Oberon-M(tm) version 1.0 for Intel 80x86 processors running MSDOS (c) Copyright E. R. Videki, 1989-1991, ALL RIGHTS RESERVED P. O. Box 58 Morgan Hill, California 95038 USA * Special Pre-Release Version* Internet address (as of March 1991) erv @ k2.everest.tandem.com IP address 130.252.59.153 This package is a complete Oberon compiler for the MSDOS environment. The code generated is in standard MSDOS object files which will run on 80x86 processors under the common MSDOS derivatives. Note that 8088 and 8086 processors are NOT supported. No warrantees are expressed or implied. The user of the contents of this package assumes full responsibility for its use, fitness for any purpose, and applications. COMPILER The compiler itself is called "oc.exe". It is run with the following command line under MSDOS: oc filename[.mod] [def] If the optional ".mod" is ommitted, the compiler will append it to the file name. The "def" option, specified just as shown, will cause a module which exports items to have a special symbol file written to disk. This is a safety feature: modules are checked at run time for consistency of level of object form with the form used for compilation. Only when you specify the "def" option after the file name will the symbol file used when compiling other modules which import this one be (re-)written on the disk. If you are writing a module that is imported by others, when you want its symbol file to be (re-)written (and used by other compiliations), you MUST specify "def" on the command line of the module that is to be imported. You do not use "def" when a module exports nothing (such as your "main" module). The compiler generates standard MSDOS object files which ultimately must be linked with the other object files representing imported Oberon modules, plus linked with the special run-time support file SYS.OBJ . LINKING OBJECT FILES A standard MSDOS linker or its equivalent will bind together the object files. There are two rules that must be followed. 1) Your "main" module (the one that is to receive control from DOS after all other modules are initialized, and which is not imported by any other module) must be named FIRST in the list of modules to link together. 2) The small run-time support object file, named SYS.OBJ must be named LAST in the list of modules to link together. An example of use: link mymain+import1+import2+sys ; ...will generate a file named "mymain.exe" which is executable (assuming your programming is correct!). OTHER FILES SUPPLIED IN THIS PACKAGE The compiler is supplied with a number of additional files in this package. Oberon Language Files: obrept.ps - Niklaus Wirth's definition of the Oberon language, which is supported by this Oberon-M(tm) compiler. obebnf.ps - The EBNF summary of the language *** Note: these files must be downloaded to a PostScript(tm) processing printer for correct formatting! *** Oberon Modules for use under MSDOS These are modules which work under most (if not all) versions of MSDOS, and which you may import into your own programs. They are provided in source form, as well as "ready to link" form, plus pre-compiled symbol forms so that you do not have to compile them before importing them. They include: Disk Disk file direct-handling IO General I/O operations LineIO Specific line-oriented file I/O LIO A version of LineIO with indentation Screen Direct-writing to many display screen types Parms Reading parameters from the MSDOS command line Term I/O specifically for keyboard and display Example Module The module Abu.mod is a full-featured example of using the Oberon-M(tm) compiler with many of the supplied modules to make a simple fast-executing, very small, full-screen file browser. (Note: Since this module uses the Screen.Mod module which may be incompatible with some types of display screens, you may have to modify Screen for your machine before Abu.mod works.) If you want to execute this example before fiddling with the source, simply type: abu and the Abu.exe file will let you browse the file you named. Utility Module The executable file "xdef.exe" is a utility program that will scan your source modules and generate a file named with a ".dfn" file extension appended to the file name. This resultant file contains a summary of the exported objects from the file. In other words, the xdef utility condenses an entire source module into only those items which are visible to clients (importers) of that module, and does not show the inner details. To execute under MSDOS, type: xdef and the result file will be generated silently. Two important notes: 1) the source should be error-free before using xdef, else xdef may have problems; 2) if you forget to specify a file name, xdef halts with an error code. OBERON-M(tm) SPECIFICS The Oberon-M compiler is source compatible with the Oberon language found under the Oberon System produced by the Swiss Federal Institute of Technology (where Niklaus Wirth is). However, there are some specifics for the MSDOS environment you must keep in mind. * User Halt codes must be greater than 100. * The SYSTEM module built-into the compiler is for MSDOS, but is the same as is defined by Niklaus Wirth in terms of exported objects. * Running under DOS requires a "main" module that does not import anything, and which must be the first one named in the list of files linked together. OTHER READING You may find more information about Oberon in the following articles: N. Wirth "Type Extensions" ACM Trans. on Prog. Languages and Systems 10,2 (April 1988) 204-214 N. Wirth "From Modula to Oberon" Software- Practice and Experience 18,7 (July 1988) 661-670 N. Wirth "The Programming Language Oberon" Software- Practice and Experience 18,7 (July 1988) 671-690 ***Note: the updated report of the language is included with this package and supercedes this report***** N. Wirth and J. Gutknecht "The Oberon System" Software- Practice and Experience 19 (September 1989) 857-893