[M3devel] Compiling Modula-3 to C

Jay K jay.krell at cornell.edu
Sat Apr 24 23:58:18 CEST 2010


I haven't read this closely yet, 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, 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), POSIX (or NT), and a C compiler, that should be all it takes.
Notice that there are now affordable and somewhat performant MIPS laptops that
  run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding
  its targets, including PowerPC, MIPS, SPARC64.


There will probably be an option to generate C++ as well, which
should offer more efficient exception handling than portable C.

Whether or not it it is all idiomatic and intuitive to interoperate with, unknown.

Regarding that paper:

One should try to remain mindful of when language change is needed vs. merely library.
   I didn't read enough to see if they need language changes.
   I do believe Modula-3 could benefit from some language changes. Though that might be mitigated
   and/or eliminated by me knowing Modula-3 better. For example, can I have a type with
   compiler-enforced opacity without requiring heap allocation?

C compilers are probably better these days.
 Look -- gcc 4.5 just caught up some with Visual C++ and others and has "LTO": link time optimization.
  I believe Sun also has had this a while, and I'm sure others.
  I rarely turn on optimization though, I admit.
  Disk and network I/O tend to dominate all costs. I don't do heavy computation.


Shared libraries are always going to seem bloated because they export everything,
even unused stuff.


The paper seems little confused on this matter, depending on the
quality/behavior of the linker, and whether or not functions are "separated" 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, so you only link in what you use, and what that references, transitive closure.
For better and for worse, data is not linked in with that same high level of granularity.
If you get any data from an object, you get it all.
And that includes pointers to functions, and whatever those functions call, 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, Sun, Mac do?)


 - Jay

----------------------------------------
> To: m3devel at elegosoft.com
> Date: Sat, 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
 		 	   		  


More information about the M3devel mailing list