Conference 7.286::atarist

88.0. "MEGAMAX Modula" by FRAMBO::PFEIFER (P(l)iss off, use Modula) Wed May 11 1988 16:21

Since nearly 8 weeks I'm now working with the new MEGAMAX-Modula-2
development system.

It's a fast one-pass compiler developed since 1985 in Germany, which 
conforms to the latest language report of N. Wirth.

It comes with a shell, which is in fact a new desktop and operating-
system. This desktop contains all functions you need for a fast
development and testing of Modula-2 software. This shell is highly
customizable, it's startup is driven by a setup-file. Last not least
the package includes the complete sources for this shell. The editor is
nice, but you can replace it by your own. I've customized the shell to
use my GEM-based MicroEmacs, I've written some scripts for MicroEmacs
to jump to the error-location (if any) and display the error-message
if it's called with this options by the compiler or the runtime system.

But this shell includes also a new operating system, called MOS (Modula
Operating System). This is needed, because the system does load-time
linking. If you start a main-module, all imported modules will be linked
at load-time. If the modules are already in memory, they are just reused,
otherwise they will be loaded from disk. After process-termination all
modules are released, if not longer referenced by any other process. Last
not least you can install modules.

So as you see, MOS is more or less a module-, memory- and process-manager.
In the libraries they are also fixing some of the well-known bugs of
GEMDOS or TOS. Very nice is also their process-termination handling, you
can build termination-envelopes around your process to do any cleanups.
They use this in their libraries for closing files, windows, 
AES-connections etc. at termination.

The libraries are complete and powerfull. Most attractive, they have written
libraries to interface GEM to Modula and not otherwise like for example the
TDI people did. So you have record-types for the VDI/AES structures,
enumerations and sets for options etc. Forget this unstructured intin[],
intout[], whatsthis[]... approach ! Coroutines and IOTransfers are supported
and they are working well.

For the most common tasks they offer procedures. So with one call you can
do all this VDI/AES initialization.

They have also a runtime-debugger, but it's just a tracer. The code 
compiled with debug-option will be executed stepwise, showing the 
source-coude in a debug-window. They don't display variables, but they
trace the evalution of expressions. But that's hard to understand if 
you have no knowledge how the compiler generates code for expression
evaluation. They told me that they are working on a real debugger
where you can set breakpoints, examine variables and all like that.

The generated code isn't optimized, because currently they are working
stack-oriented. So they do no register optimization and this results in
poor code. They say that they are working on this.

Also the linker, which is used to produce a ordinary GEM/TOS program,
isn't optimizing. All procedures of a imported module are linked into
the final image, so the .PRG/.TOS files becomes rather big. They say,
as usual, they are working on this.


Until now I've found some bug's:

1. If there is a cycle in the import-graph ( A import proc f from B, 
   B import proc g from A), they run into a problem at termination. None
   of both will be released because they are thinking they are used from an
   other module. So more or less the whole program remains in memory. If
   you start it again, the modules will not be initialized, because they are
   marked as loaded and initialized, so normally your program will crash.
   You have to restart the shell.

2. If you have a BITSET type-transfer in a CONST declaration, this
   produces wrong code (seems always to be the void set).

3. Division by negative reals produces nonsense.

4. If you have local modules in implementation modules which are exporting
   identifiers to the world, this will confuse the compiler and he starts
   to do unexpected things.

All this bugs will be fixed in the next release as they told me.

I think it's a powerfull development-system, better than any other on the
ST (you won't agree of course if you are a 'C' prayer). I had no problem
to compile and run large packages I've written in the last years using
modula-2. I just did the usual adaption for non-standard libraries and
of course used workarounds for the bugs (very simple). 
The bugs are not essential, you can live with them and hope for the
next release.

If you have any replies, please don't expect any answers before June,
because I'm not in the office for the next two weeks.

J�rgen
 

    
    
    	please refer to 13.27
    
    regards,
    hermann