MHC Modula-2

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Recently I came across the MHC Modula-2 compiler. It is something in
between a true native compiler and a cross compiler and a translator.
In short: it compiles to java source files, which then can be compiled
into java bytecode class-files and then they can be used across
platforms.

I did a fair amount of tests and came to the conclusion that this is
what I am looking for. I can program in Modula-2 and all my
executables (packed in a JAR file) can be run on any modern day
operating system. And since java executables run without their .java
source files, the thought behind the Modula-2 concept (i.e. code
hiding) remains intact.

MHC increased the functionality of their compiler by adding type
inheritance and exrension. Memory managenemt is done by Java so there
is no need for DISPOSE or ALLOCATE.

See also http://fruttenboel.verhoeven272.nl/mhc/index.html for more
details.

MHC also sell versions for Oberon and Pascal. This is the best
compiler I came across in this century (and millenium). :o)

[Marco van de Voort]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
Recently I came across the MHC Modula-2 compiler. It is something in
between a true native compiler and a cross compiler and a translator.
In short: it compiles to java source files, which then can be compiled
into java bytecode class-files and then they can be used across
platforms.

I've had a look at your site, and examples like
http://fruttenboel.verhoeven272.nl/mhc/index.html

where a bit shocking to be honest. For any compiler that compiles to
whatever backend, you don't want it to be needed to know the language of the
backend to diagnose compiler problems. That is the task of the compiler.
Either it compiles and runs, or not.

Even the compilers you routinely dismiss in your ramblings, don't give
"assembling" errors if the modula2 or C is accepted.

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Hello marco

Thank you for your kind comments. I appreciate you took the energy to
read things.

Post by Marco van de Voort
where a bit shocking to be honest.

^ syntax error... :o)

The compiler compiles errorfree and clean. I had to make some slight
modifications to the FileSystem Module. I did that with FST. I did
that with Mocka. I did that with MHC.

Post by Marco van de Voort
For any compiler that compiles to whatever backend, you don't want it to
be needed to know the language of the backend to diagnose compiler problems.

There are no compiler problems. I did not mention one single compiler
problem. You must have read that on another site, not on mine.

For the record: the compiler is written in Java. It comes as a JAR
file and runs on ALL operating systems: Linux, Mac, Windows, whatever.
And it produces code that runs on ALL operating systems as well. And
the MHC compiler is nearly 100% PIM.

[Marco van de Voort]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa

Post by Marco van de Voort
where a bit shocking to be honest.

^ syntax error... :o)
The compiler compiles errorfree and clean. I had to make some slight
modifications to the FileSystem Module. I did that with FST. I did
that with Mocka. I did that with MHC.

I think my mistake was that I missed the part it was calling inline java.
I'm not used to scan for inline HLL, and inline asm is more distinctly
recognizable. So forget my comments.

I thought an ordinary argument parsing code could compiler fine with mhc,
but not with Java (IOW mhc only being a thin compiler).

However the inline java is probably outside the compilers box of control,
and that is no problem (nobody complains if Delphi code blows skyhigh due to
bad internal asm either)

[Objective Modula-2]

Post by Marco van de Voort
However the inline java is probably outside the compilers box of control,
and that is no problem (nobody complains if Delphi code blows skyhigh due to
bad internal asm either)

The MHC compiler generates Java source code, not even JVM bytecode. It
requires an actual Java compiler to compile the output afterwards. For
this reason, it can afford to simply copy the inline java code into
its output and leave it up to the java back-end compiler to verify and
compile it. It doesn't need to do any processing of the java code. If
it does, its icing on the cake.

[Marco van de Voort]

Post by Objective Modula-2

Post by Marco van de Voort
However the inline java is probably outside the compilers box of control,
and that is no problem (nobody complains if Delphi code blows skyhigh due to
bad internal asm either)

The MHC compiler generates Java source code, not even JVM bytecode. It
requires an actual Java compiler to compile the output afterwards. For
this reason, it can afford to simply copy the inline java code into
its output and leave it up to the java back-end compiler to verify and
compile it. It doesn't need to do any processing of the java code. If
it does, its icing on the cake.

I do understand this. Your statement, while it might work for mhc (always?)
is not general though. It only goes for very 1:1 mappings of source onto
destination language. (which MHC could be btw, don't know it well enough to
judge that)

Example: If the xx-to-java does some mapping (mangling) on the variables,
the inline code needs to be parsed so that M2 variables are substituted with
their proper mangled counter part.

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Post by Marco van de Voort
Example: If the xx-to-java does some mapping (mangling) on the variables,
the inline code needs to be parsed so that M2 variables are substituted with
their proper mangled counter part.

Here's the directory listing of one (small) project:

***@Beryllium:~/modula/mhc/3$ ls
Conversions.class SYSTEM_PADDRESS.class SYSTEM_PHUGEINT.class
SYSTEM_PLONGWORD.class SYSTEM_PWORD.class
Conversions.java SYSTEM_PADDRESS.java SYSTEM_PHUGEINT.java
SYSTEM_PLONGWORD.java SYSTEM_PWORD.java
FileSystem.class SYSTEM_PBOOLEAN.class SYSTEM_PINTEGER.class
SYSTEM_PROC.class Strings.class
FileSystem.java SYSTEM_PBOOLEAN.java SYSTEM_PINTEGER.java
SYSTEM_PROC.java Strings.java
FileSystem_File.class SYSTEM_PBYTE.class SYSTEM_PLONGCARD.class
SYSTEM_PSHORTCARD.class dum1.mod
FileSystem_File.java SYSTEM_PBYTE.java SYSTEM_PLONGCARD.java
SYSTEM_PSHORTCARD.java dum2.class
InOut.class SYSTEM_PCARDINAL.class SYSTEM_PLONGINT.class
SYSTEM_PSHORTINT.class dum2.java
InOut.java SYSTEM_PCARDINAL.java SYSTEM_PLONGINT.java
SYSTEM_PSHORTINT.java dum2.mod
SYSTEM.class SYSTEM_PCHAR.class SYSTEM_PLONGREAL.class
SYSTEM_PSHORTREAL.class
SYSTEM.java SYSTEM_PCHAR.java SYSTEM_PLONGREAL.java
SYSTEM_PSHORTREAL.java
***@Beryllium:~/modula/mhc/3$

***@Beryllium:~/modula/mhc/3$ cat dum2.mod
MODULE dum2;

IMPORT FileSystem, InOut;

VAR inF : FileSystem.File;
ch : CHAR;

BEGIN
FileSystem.OpenReader (inF, "dum2.mod");
IF inF.res = FileSystem.done THEN
InOut.WriteString ("File 'dum1.mod' opened");
InOut.WriteLn;
FileSystem.ReadChar (inF, ch);
WHILE inF.eof = FALSE DO
InOut.Write (ch);
FileSystem.ReadChar (inF, ch)
END;
FileSystem.Close (inF)
ELSE
InOut.WriteString ("File not found");
InOut.WriteLn
END;
InOut.WriteLn
END dum2.

So it looks like java files are made for every single entity by the
mhc compiler. With 'javac *.java' the class files are made.

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
So it looks like java files are made for every single entity by the
mhc compiler. With 'javac *.java' the class files are made.

all in all, the mhc compiler is a bit of a disappointment. Bigger
projects are hard to implement. or I am doing very wrong.

[Chris Burrows]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
So it looks like java files are made for every single entity by the
mhc compiler. With 'javac *.java' the class files are made.

all in all, the mhc compiler is a bit of a disappointment. Bigger
projects are hard to implement. or I am doing very wrong.

On your webpage you say:

"Could I convince Niklaus Wirth to come out with an Oberon or Modula-2
compiler that produces Java byte code?"

Did you know about the Gardens Point Component Pascal (i.e. Oberon-2+)
compiler that generates Java byte code?

http://plas.fit.qut.edu.au/gpcp/Information.aspx

I haven't used the JVM-targeted version myself but have written 20,000+
lines of code in the .NET targeted version of GPCP without any problems.
Full source code of the compilers is provided. Like most good compilers of
Wirthian languages they are almost entirely implemented in their own
language which is an excellent way of detecting bugs early ;-)

QUT have also been supporting Modula-2 compilers for many years and did port
it to .NET (the clr versions) but I can't see a JVM Modula-2 compiler. It
seems they used their own form of intermediate code in those days:

http://plas.fit.qut.edu.au/gpm/

Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Post by Chris Burrows
"Could I convince Niklaus Wirth to come out with an Oberon or Modula-2
compiler that produces Java byte code?"

Correct.

Post by Chris Burrows
Did you know about the Gardens Point Component Pascal (i.e. Oberon-2+)
compiler that generates Java byte code?

Yes. I tried to install it. Couldn't get it working.

[modsquad]

Nice site!

Q1.) Will the XREF.mod and EBNFScanner/EBNF/TableHandler examples from
N. Wirth, "Programming in Modula-2", 3rd edition, compile and run
under MHC Modula-2?

Q2.) If not, what changes are needed to get above examples to compile
and run under MHC Modula-2?

Thanks in advance for any help here.

Sincerely
Modulan1
The ModuleSquad

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
Recently I came across the MHC Modula-2 compiler.

<snip...>

[Ólafur Gunnlaugsson]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
Recently I came across the MHC Modula-2 compiler. It is something in
between a true native compiler and a cross compiler and a translator.
In short: it compiles to java source files, which then can be compiled
into java bytecode class-files and then they can be used across
platforms.

It is a nice enough compiler as far as it goes, based on the old MHC
PIM4 compiler that generated native 16 DOS and Windows apps in
addition to 32 bit OS/2 apps that I still uses from time to time, but
the Java compiler does not see too much development these days since
there seems to be no interest in general for M2, or in M2 on Java for
that matter

It has been around for some 10 years nota bene so I am a bit surprised
that people are finding it just now .....

Some of the "non standards" you mention on your web page are actually
not non standard at all they hark to the days of the original MHC x86
compiler and the fact that it was the only compiler that actually
implemented PIM4, and all other compilers use PIM 1 to 3, PIM 4 is
slightly different to the earlier definitions and to ISO.

PIM4 is BTW impossible to get hold of and was so even in the early
1990's when I tried to order a copy from Springer.

[Duke Normandin]

[snip]

Post by Ólafur Gunnlaugsson
PIM4 is BTW impossible to get hold of and was so even in the early
1990's when I tried to order a copy from Springer.

Isn't this:

http://freepages.modula2.org/report4/modula-2.html

not it?

[Ólafur Gunnlaugsson]

Post by Duke Normandin
[snip]

Post by Ólafur Gunnlaugsson
PIM4 is BTW impossible to get hold of and was so even in the early
1990's when I tried to order a copy from Springer.

http://freepages.modula2.org/report4/modula-2.html
not it?

Lovely, thanks

Only 20 years too late

[Chris Burrows]

Post by Ólafur Gunnlaugsson
implemented PIM4, and all other compilers use PIM 1 to 3, PIM 4 is
slightly different to the earlier definitions and to ISO.

The only language difference I was aware of between PIM3 and PIM4 was the
definition of the behaviour of the MOD operator. Was there anything else?

Regards,
Chris Burrows

CFB Software
http://www.cfbsoftware.com/modula2