[M3devel] new target? :)

[Jay K]

When you write that system that doesn't have the support of any C compiler, sure, go ahead and
write a backend just for it, and maybe a linker, and rewrite the small parts that depend on C and Posix in some
sort of native way -- including writing all the underlying stuff.
 
 
Getting Modula-3 working on that system will be a relatively small task, compared to whatever else
   is needed to build the system.
 
Note for example, we can't e.g. open files in Modula-3, w/o underlying Win32 or Posix functionality.
  Everywhere that varies for Win32 vs. Posix would have to be revisited in this hypothetical system.
 
 
This has little/no bearing on the vast vast vast vast majority of real world systems.
The current Modula-3 system is NOT implemented entirely in Modula-3.
It MUST depend on SOMETHING.
So far, for the vast vast vast vast vast majority of systems, that something is written in C,
and has a C runtime, compiler, and linker.
 
 
Yes, I've heard of SPIN.
 
 
You know..how are you actually going to network I/O or keyboard I/O or power management
or video I/O or mouse I/O or sound I/O or preemptive multi-processor scheduling?
You need device drivers. You need a processor-specific context switcher.
i.e. you need a kernel and you need C AND/OR you need to do a lot of work.
 
 
If you consider that our system is already forked along Win32 and Posix lines, you can consider
these hypothetical systems a third (fourth, fifth, etc.) fork. A third (fourth) implementation
of threading. A third implementation of file I/O. A third implementation of Trestle. etc.
 
 
But this has little/no bearing how we should target existing real systems.
 You can say, not that "Modula-3 depends on C (runtime, compiler, linker)", but that "Modula-3 on Linux, NT, *BSD, Solaris, Darwin
depends on C (runtime, compiler, linker)", and there's absolutely nothing wrong with that, as C and C++
are well supported on those systems and always will be. Increasing that dependency, on those systems, is fine.
 
 
It would be nice to port the integrated backend to lots more systems, and to write our own linker.
But not easy.
And notice how the integrated backend also has the worst debugging story of the two/three options, currently.
 (I say three options because m3cg kind of has two modes, one is incomplete and currently disabled,
  the other requires m3gdb).
 
 
One problem I see here, is that, you kind of sort of maybe forseeable want a backend that outputs Java or C#.
  C# particularly for Windows Phone 7/Nokia.
  Java kind of for Android, where Java is preferred over C/C++.
 
 
i.e. there are systems that sort of lack C and C++. Not that they replace it with Modula-3 though.
 
 
However this isn't super easy, like if you are to include the existing m3core/garbage collector.
C# is optionally safe. I don't know if it would serve as a good target.
  (Optional safety imho makes C# among one of the closest languages to Modula-3. It is
  missing "compile to native", but that maybe is a good thing.)
In addition, C# and Java do each compile down to one well documented "object" file format,
so maybe skipping the text is probably sensible. Esp. since with C# there are in-proc libraries for codegen.
 
 
More likely, if a Java/C# target were really needed, it'd include forking within m3core 
and replace the garbage collector. This is all highly specuative stuff.
 
 
 - Jay

 
> To: jay.krell at cornell.edu
> Date: Thu, 24 Feb 2011 17:31:00 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] new target? :)
> 
> Jay K writes:
> ...
> >m3cg is=2C technically=2C a gcc frontend=2C 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=2C the =
> >GPL doesn't cross the barrier=2C
> >leaving cm3/m3front=2C and more importantly=2C m3core/libm3=2C not GPL.
> >=20
> >=20
> >I do wonder if m3cg/cm3/m3front/m3core/libm3 could be LGPL to please RMS.
> >=20
> >=20
> 
> Good points all about C but I wonder about what is really lost. Also ......
> Modula-3 is supposed to be portable to systems without C. You're supposed
> to be able to write an entire system in Modula-3. Ok generating C obviously
> doesn't break that feature but you might have to worry a bit about having
> too much C sneak into the runtime libraries.
> 
> Well given that CM3 is released under what is more or less an MIT/BSD license, 
> I think the problem is rather that Some Evil Software Company could write
> a completely non-free front-end and use m3cg to generate code...
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110225/6b68fe79/attachment-0002.html>