[M3devel] new target? :)

[Tony Hosking]

Just to follow up briefly as I have lots of other things on my plate.
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.

On Feb 24, 2011, at 8:55 PM, Jay K wrote:

> 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/dd0b424d/attachment-0002.html>