<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
#line directives should help source debugging.<br>I agree the types would be a bit off. For example arrays, objects, texts, would have internals showing,<br>and texts might take extra steps to see what you really want.<br><br> - Jay<br><br><hr id="stopSpelling">Subject: Re: [M3devel] new target? :)<br>From: hosking@cs.purdue.edu<br>Date: Fri, 25 Feb 2011 10:08:15 -0500<br>CC: mika@async.caltech.edu; m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML"><base>Just to follow up briefly as I have lots of other things on my plate.<div>One of the reasons for targeting the gcc-based backend was to support easy generation of *source*-level debugging information. It is important that the debugger see types as Modula-3 sees them, rather than as C types generated form the Modula-3. Now, I agree that debugging the C-translated types is probably better than nothing.<br>
<br><div><div>On Feb 24, 2011, at 8:55 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">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<span class="ecxApple-converted-space"> </span><br>and replace the garbage collector. This is all highly specuative stuff.<br> <br> <br> - Jay<br><br> <br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> Date: Thu, 24 Feb 2011 17:31:00 -0800<br>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a><br>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] new target? :)<br>><span class="ecxApple-converted-space"> </span><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>><span class="ecxApple-converted-space"> </span><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>><span class="ecxApple-converted-space"> </span><br>> Well given that CM3 is released under what is more or less an MIT/BSD license,<span class="ecxApple-converted-space"> </span><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>><span class="ecxApple-converted-space"> </span><br>> Mika<br></div></span></blockquote></div><br></div> </body>
</html>