Oberon-M Q's and A's

This is about the Oberon-M(tm) package for the MSDOS environment. Here
are answers to questions that I've been repeatedly asked:


Q: Does this use real Intel/MSDOS-like object files?
A: Yes, in fact in a form that I expect is even compatible with all older
      releases. This causes some non-Intel-based linkers (such as one from
      Borland) to give occasional warning messages, but everything works fine
      even under those cases.


Q: What kind of garbage collector do you use?
A: The MSDOS environment (particularly older releases) don't work well with
      programs taking over full storage management -- especially when many and
      varied terminate and stay resident programs are present. As with Oberon
      itself, simplicity is refreshing, so although I once had a garbage
      collector its use was questionable under DOS, and it is not present in
      this package. You can, of course, do NEW(objectptrs) on anything that
      will fit, but there is no automatic retrieval of storage (until your
      program ends). Of course you could always write your own storage manager
      (it can be very powerful while still being very simple).


Q: What about the Oberon System?
A: As explaned in different words in my earlier posting, the Oberon system
      is an extensible operating environment with user interfaces and automatic
      storage management. MSDOS likes to own these things all by itself mostly.
      My compiler and package is best thought of as a way to write programs
      using the advanced and elegant features of Oberon in the popular MSDOS
      world.


Q: What's the product's official name?
A: It is called Oberon-M(tm), and I hold the trademark rights as well as
      copyrights to it. Further, it is my sole intellectual property. It is
      being released in the form of license-to-use.


Q: What about other legal requirements, etc ?
A: The package itself specifies these, but a summary of
      the details are:
       1) I retain full copyright of this package, especially the compiler
and the implementation approach.
       2) Use of the package is by license, at the moment with fee waved.
The user does not own the package, only has rights to use it.
       3) The user may not redistribute the package or the compiler or the
associated tools to other users, in any way. This means I don't
want it given out by third parties, and of course never sold by
them, nor represented as being their property. Network
distribution is an exception to the prohibition of
       multi-level distribution.
       4) Users may write programs, use the distributed library modules with
their programs, and even modify for their own use the library
       modules (but not the compiler). Such user programs may be
distributed without fee or royalties to me.
       5) My copyright notices may never be removed from
       the package contents itself.
       6) No warrantees or guarantees are expressed or implied. Use of the
package in any and all ways is entirely the user's responsibility
       and risk.


Q: How long will use of this be "no charge", ie: the license fee is waved?
A: On this release, no specific period has been decided upon.


Q: What are the specific, technical things the compiler does not do?
A: Here are the things that the compiler does NOT do now, or could be viewed
      by some as being deviations from the Oberon language report by Niklaus
      Wirth:
1) No floating point support in this release.
2) 8088 and 8086 (ie: the oldest processors) do not have Enter and
Leave instructions which are generated by the compiler. Thus,
only PCs with 80x86 (where x >= 1) processors can use the
produced code. The compiler itself will run on an older machine,
though.
3) The produced code has not been tested under all versions of MSDOS
that exist in the world, but I anticipate no problems. Some of
the library modules may have differences in internal calls for
very-odd MSDOS flavors; source for these are supplied so you may
make modifications if you are running one of these rare DOS
systems.
4) The ETH Zurich Oberon System permits "code procedures" identified
by a minus sign in the procedure header. This is non-standard,
very machine dependent, and not allowed on my compiler.
However, module SYSTEM exports a predefined CODE procedure which
takes bytes to insert in the instruction stream.
5) You MUST use the compiler hint "*" on a procedure definition if
that procedure is going to be assigned to a procedural-typed
variable (so that 80x86 long-calls will be generated). This
looks like this, and is part of the Oberon language:
PROCEDURE * MyHandler(....
Trying to assign a procedure without the "*" indicator results
in a type incompatibility error at compile time. Note that this is
different than the export mark "*" which follows the procedure
name.
                6) Due to the irregularities of the 80x86 architecture, code
generation for it is ponderous. In my experience most professional
programmers don't need or want the overhead of range or stack
                      checking, so that is not provided. Of course, this is a debatable
issue.
                7) To make very sure programs using system dependent features (ie:
the built-in machine specific system support module) are identified
                      by the compiler, our system support module is called "SYS" (whereas
the one from ETH is named "SYSTEM"). Excepting the exported
                      CODE procedure, it functions the same as defined as SYSTEM in
Niklaus Wirth's report. I am considering changing this name to
SYSTEM in the next release, and if you have a strong
   opinion, please tell me about it.


Q: Can't I please get this package in some way other than
      FTP or uudecode of mail messages ?
A: Sorry, the demand is too great to respond to special requests for free.


Q: What's the size of the whole package?
A: In compressed (ZIP) format, it is about 151K, expanding to about 250K or
      so, including the PostScript(tm) documentation. In uuencode format (in
      mail messages) it is about 210K. The compiler itself is merely 78K.


Q: What's in the package, specifically?
A: Compiler, library modules in source/symbolic/object forms, sample programs,
      an extensive README file instructing how to use the package, a report on
      the Oberon language, and an EBNF summary of the syntax (these must be
      downloaded to a PostScript-handling printer or printer driver).


Q: "I sent you a logon/password/subdirectory to put the files on my machine.
      What are you going to do with that information now that you are
      distributing this package through anonymous FTP and uudecode mail?"
A: Nothing. It is destroyed as confidential information. I come from the
      old school of hacking that respects privacy as a rule of existence.


-- E. R. Videki 18 March 91
      erv @ k2.tandem.everest.com (130.252.59.153)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.