<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
When you write that system that doesn't have the support of any C compiler, sure, go ahead and<BR>
write a backend just for it, and maybe a linker, and rewrite the small parts that depend on C and Posix in some<BR>
sort of native way -- including writing all the underlying stuff.<BR>
<BR>
<BR>
Getting Modula-3 working on that system will be a relatively small task, compared to whatever else<BR>
is needed to build the system.<BR>
<BR>
Note for example, we can't e.g. open files in Modula-3, w/o underlying Win32 or Posix functionality.<BR>
Everywhere that varies for Win32 vs. Posix would have to be revisited in this hypothetical system.<BR>
<BR>
<BR>
This has little/no bearing on the vast vast vast vast majority of real world systems.<BR>
The current Modula-3 system is NOT implemented entirely in Modula-3.<BR>
It MUST depend on SOMETHING.<BR>
So far, for the vast vast vast vast vast majority of systems, that something is written in C,<BR>
and has a C runtime, compiler, and linker.<BR>
<BR>
<BR>
Yes, I've heard of SPIN.<BR>
<BR>
<BR>
You know..how are you actually going to network I/O or keyboard I/O or power management<BR>
or video I/O or mouse I/O or sound I/O or preemptive multi-processor scheduling?<BR>
You need device drivers. You need a processor-specific context switcher.<BR>
i.e. you need a kernel and you need C AND/OR you need to do a lot of work.<BR>
<BR>
<BR>
If you consider that our system is already forked along Win32 and Posix lines, you can consider<BR>
these hypothetical systems a third (fourth, fifth, etc.) fork. A third (fourth) implementation<BR>
of threading. A third implementation of file I/O. A third implementation of Trestle. etc.<BR>
<BR>
<BR>
But this has little/no bearing how we should target existing real systems.<BR>
You can say, not that "Modula-3 depends on C (runtime, compiler, linker)", but that "Modula-3 on Linux, NT, *BSD, Solaris, Darwin<BR>
depends on C (runtime, compiler, linker)", and there's absolutely nothing wrong with that, as C and C++<BR>
are well supported on those systems and always will be. Increasing that dependency, on those systems, is fine.<BR>
<BR>
<BR>
It would be nice to port the integrated backend to lots more systems, and to write our own linker.<BR>
But not easy.<BR>
And notice how the integrated backend also has the worst debugging story of the two/three options, currently.<BR>
(I say three options because m3cg kind of has two modes, one is incomplete and currently disabled,<BR>
the other requires m3gdb).<BR>
<BR>
<BR>
One problem I see here, is that, you kind of sort of maybe forseeable want a backend that outputs Java or C#.<BR>
C# particularly for Windows Phone 7/Nokia.<BR>
Java kind of for Android, where Java is preferred over C/C++.<BR>
<BR>
<BR>
i.e. there are systems that sort of lack C and C++. Not that they replace it with Modula-3 though.<BR>
<BR>
<BR>
However this isn't super easy, like if you are to include the existing m3core/garbage collector.<BR>
C# is optionally safe. I don't know if it would serve as a good target.<BR>
(Optional safety imho makes C# among one of the closest languages to Modula-3. It is<BR>
missing "compile to native", but that maybe is a good thing.)<BR>
In addition, C# and Java do each compile down to one well documented "object" file format,<BR>
so maybe skipping the text is probably sensible. Esp. since with C# there are in-proc libraries for codegen.<BR>
<BR>
<BR>
More likely, if a Java/C# target were really needed, it'd include forking within m3core <BR>
and replace the garbage collector. This is all highly specuative stuff.<BR>
<BR>
<BR>
- Jay<BR>
<BR> <BR>
> To: jay.krell@cornell.edu<BR>> Date: Thu, 24 Feb 2011 17:31:00 -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>> >m3cg is=2C technically=2C a gcc frontend=2C 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=2C the =<BR>> >GPL doesn't cross the barrier=2C<BR>> >leaving cm3/m3front=2C and more importantly=2C m3core/libm3=2C not GPL.<BR>> >=20<BR>> >=20<BR>> >I do wonder if m3cg/cm3/m3front/m3core/libm3 could be LGPL to please RMS.<BR>> >=20<BR>> >=20<BR>> <BR>> Good points all about C but I wonder about what is really lost. Also ......<BR>> Modula-3 is supposed to be portable to systems without C. You're supposed<BR>> to be able to write an entire system in Modula-3. Ok generating C obviously<BR>> doesn't break that feature but you might have to worry a bit about having<BR>> too much C sneak into the runtime libraries.<BR>> <BR>> Well given that CM3 is released under what is more or less an MIT/BSD license, <BR>> I think the problem is rather that Some Evil Software Company could write<BR>> a completely non-free front-end and use m3cg to generate code...<BR>> <BR>> Mika<BR> </body>
</html>