<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I never used the system, but one can imagine and it has been said here:<BR>
slower to compile <BR>
less good debugging -- and also better debugging! <BR>
<BR>
<BR>
However I still think the large gain in portability, and the actual *gain* in debuggability,<BR>
would be very worthwhile. (There are pluses and minuses for debugging;<BR>
you'd get to use gdb instead of m3gdb, and have C syntax).<BR>
<BR>
You'd gain portability and ports to various real, old, existing, new systems.<BR>
e.g. NT/IA64, NT/AMD64, Android, NativeClient.<BR>
<BR>
<BR>
You'd gain a "standard" distribution format of just source.tar.gz + possibly ./configure + make + make install.<BR>
The that's a little more work.<BR>
<BR>
I think there's some issue with the metadata for garbage collection.<BR>
I think we maybe store frame offsets for locals?<BR>
We'd maybe have to put all locals in a struct or such?<BR>
Impeding optimization?<BR>
<BR>
Similarly, nested functions would need some handling.<BR>
<BR>
<BR>
You would also gain tremendously better exeption handling implementation.<BR>
You'd generate C on NT/VMS/OSF1, and use __try/__except/__finally there.<BR>
You'd generate C++ for all others and use try/catch/finally.<BR>
You'd get stack walking on essentially all platforms.<BR>
Except for the small number of platforms that use setjmp/longjmp for C++ exception handling.<BR>
<BR>
In some cases you'd get better codegen, as gcc is often not the best.<BR>
<BR>
<BR>
RMS's problem is that normally the gcc frontends and backends are statically linked.<BR>
frontends: C, C++, Java, Ada<BR>
Therefore the frontends get infected by the GPL. Good in RMS opinion.<BR>
<BR>
<BR>
m3cg is, technically, a gcc frontend, and therefore GPL.<BR>
However its input is not human authored text.<BR>
Its input is the output of a "real" front end -- m3front/cm3.<BR>
By making the "call mechanism" be write to a file and run a process, the GPL doesn't cross the barrier,<BR>
leaving cm3/m3front, and more importantly, m3core/libm3, not GPL.<BR>
<BR>
<BR>
I do wonder if m3cg/cm3/m3front/m3core/libm3 could be LGPL to please RMS.<BR>
<BR>
<BR>
- Jay<BR> <BR>
> To: jay.krell@cornell.edu<BR>> Date: Thu, 24 Feb 2011 14:15:51 -0800<BR>> From: mika@async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] new target? :)<BR>> <BR>> Jay K writes:<BR>> ...<BR>> >Ultimately..you can tell what I'm going to say..a good solution is Modula-3=<BR>> >-to-C=2C and then use whatever C compiler you want.<BR>> >Including the nativeclient gcc. An iPhone/iPad/iPod cross compiler. Older s=<BR>> <BR>> I'm still curious why they abandoned this path. The first M3 compilers<BR>> all generated C code. I read something about a Modula-2 compiler that<BR>> was generating C code and therefore had problems with.. something.<BR>> <BR>> Also isn't the back-end m3cg actually quite an interesting program in<BR>> its own right? You could imagine targeting other language front-ends<BR>> to that back-end. I understand it is a good enough idea that RMS was<BR>> very annoyed that m3cg even exists.<BR>> <BR>> Mika<BR> </body>
</html>