[M3devel] new target? :)

[Jay K]

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