[M3devel] Compiling Modula-3 to C

[Mika Nystrom]

Jay,

My point in sharing that was not to agitate for making the changes in
Modula-3 that Rustan did for his project.  (It's his M.S. thesis.)

I wanted to show the quality of the assembly code that one existing
Modula-3-to-C-to-ASM toolchain has generated.  It doesn't look
*horrendous* to me, honestly, only maybe the footprint is a bit on the
large side.  One thing one could try of course is to type in Rustan's 
generated C code and compare what gcc spits out from compiling it it to
the ASM generated by compiling the original M3 code.  (On one's favorite
modern architecture.)

I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is
in there, and most of it is in the SRC sources anyhow.  MIPS especially.
No need to write a brand new one.

No you cannot have a type with compiler-enforced opacity without requiring
heap allocation.  It's a shortcoming of the language, yes.  But you know,
you can just leave a comment that says the type is opaque.  

The point of M3's safety rules is to prevent unchecked runtime errors.

M3's opaqueness rules are defined in terms of OBJECT which are always
references.  The designers felt that the C++ objects were too hard to
achieve.

BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of
anal-retentive OO people completely wrong (I think it is brilliant).
They would have you declare in your object type who can touch the
bits of it.  friends, protected, etc.  In Modula-3 it's mostly up to
the *client* to decide how much opaqueness is right. 

For example:

INTERFACE Q;        TYPE     T <: Public;   END Q.

INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends.

INTERFACE QPrivate; REVEAL Q.T <: Private;  END QPrivate.

A client R of Q can then go ahead and IMPORT QFriends and QPrivate as
it pleases, regardless of what the relationship between R and Q is.
(There is a hack in quake to hide certain interfaces but it's only 
done at one level and it's not part of the Modula-3 language proper.)

Thus, Modula-3 assumes that programmers are a bit more responsible than
the hiding rules available in C++ or Java.  Which is why I say that
not having the opaqueness available for non-ref types is not such a big
deal, really.  The language is trying to help you not make stupid 
mistakes---it's not some kind of "OO cleanliness police".

I have written a lot of M3 code and have indeed missed opaque nonreference
objects from time to time, but you learn to live with it, just like
you learn to live with the idiosyncracies of any programming language.
>From personal experience all I can say is that M3's idiosyncracies
are far less annoying than those of any other "practical" programming
language I've ever used.  (This is not a criticism, but how much M3 have
you actually written?)

Oh, regarding link-time optimization, see:

http://www.modula3.org/threads/2/#linkTimeOptimization

    Mika



Jay K writes:
>
>I haven't read this closely yet=2C I admit.
>
>
>I'm sure we'll get a Modula-3 to C backend before much longer.
>It greatly increases your real and theoretical platform support for
>one medium upfront cost=2C and perhaps a little bit of ongoing maintenance =
>if some oddities are reported.
>I'll be tired of the old way fairly soon.
>There remain too many viable but unsupported targets.
>If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C=
> that should be all it takes.
>Notice that there are now affordable and somewhat performant MIPS laptops t=
>hat
>=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding
>=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64.
>
>
>There will probably be an option to generate C++ as well=2C which
>should offer more efficient exception handling than portable C.
>
>Whether or not it it is all idiomatic and intuitive to interoperate with=2C=
> unknown.
>
>Regarding that paper:
>
>One should try to remain mindful of when language change is needed vs. mere=
>ly library.
>=A0=A0 I didn't read enough to see if they need language changes.
>=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou=
>gh that might be mitigated
>=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can =
>I have a type with
>=A0=A0 compiler-enforced opacity without requiring heap allocation?
>
>C compilers are probably better these days.
>=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "=
>LTO": link time optimization.
>=A0 I believe Sun also has had this a while=2C and I'm sure others.
>=A0 I rarely turn on optimization though=2C I admit.
>=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu=
>tation.
>
>
>Shared libraries are always going to seem bloated because they export every=
>thing=2C
>even unused stuff.
>
>
>The paper seems little confused on this matter=2C depending on the
>quality/behavior of the linker=2C and whether or not functions are "separat=
>ed" within
>object files. Visual C++ has the -Gy flag which you should *always* use.
>I don't know why it is an even an option. It makes each function within an =
>object
>separate=2C so you only link in what you use=2C and what that references=2C=
> transitive closure.
>For better and for worse=2C data is not linked in with that same high level=
> of granularity.
>If you get any data from an object=2C you get it all.
>And that includes pointers to functions=2C and whatever those functions cal=
>l=2C even
>if the data isn't referenced.
>
>
>I know that historically linkers didn't strip out anything.
>I'm surprised such linkers existed. Are they still in use?
>(What do GNU=2C Sun=2C Mac do?)
>
>
>=A0- Jay
>
>----------------------------------------
>> To: m3devel at elegosoft.com
>> Date: Sat=2C 24 Apr 2010 14:29:52 -0700
>> From: mika at async.async.caltech.edu
>> Subject: [M3devel] Compiling Modula-3 to C
>>
>>
>> The question of making a Modula-3 compiler emit C code as output comes
>> up on this mailing list from time to time.
>>
>> I just discovered a reference to a real example of this.
>>
>> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf
>>
>> Note pages 49-50 (54-55 in the PDF).
>>
>> I also find the byte counts on page 49 interesting. I wish my m3core
>> were that small!
>>
>> Mika
> 		 	   		  =