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