<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>Gcc support is becoming harder and harder to get not here precisely in gcc camp.<br>I agree with somethings you say, like good backend debugging support, but we need really get serious about implementation alternatives, it would be wonderful to support JIT targets (read, JVM, .NET, C-like machines), and obviously they are better to be written in C substrate (we need one hardware abstraction layer).<br>If you could just reuse m3cc to make a throw prototype of a JIT compiler for instance to  C-like bytecode (in form of inline assembly of gcc) the approach of C generating backend would be lot more easier to support, because you can create binary translators with NJ machine code toolkit translators for instance to several platforms using either C or Modula-3 decoding.<br>Kind of supporting <br>Thanks in advance<br><br>--- El <b>mié, 6/2/13, Coleburn,
 Randy <i><rcolebur@SCIRES.COM></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Coleburn, Randy <rcolebur@SCIRES.COM><br>Asunto: Re: [M3devel] Compiler upgrade broken in Hudson CI<br>Para: "m3devel@elegosoft.com" <m3devel@elegosoft.com><br>Fecha: miércoles, 6 de febrero, 2013 18:13<br><br><div class="plainMail">I concur with Rodney, we must preserve the m3gdb capability and the backends that support it!<br>--Randy Coleburn<br><br>-----Original Message-----<br>From: Rodney M. Bates [mailto:<a ymailto="mailto:rodney_bates@lcwb.coop" href="/mc/compose?to=rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a>] <br>Sent: Wednesday, February 06, 2013 12:25 PM<br>To: <a ymailto="mailto:m3devel@elegosoft.com" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI<br><br><br><br>On
 02/05/2013 02:28 AM, Jay K wrote:<br>> I will fix it, but I do desire to drop the old backend entirely.<br>> What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded.<br>> I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms.<br>><br><br><br>I am not sure what is happening here, but it is making me very nervous with talk of removing backends.<br><br>I have put in a *huge* amount of work on m3gdb.  While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence.  Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic
 debugger.<br><br>Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc.  etc.<br><br>A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information.  Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its<br>Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more.  As I recall it, only the release branch supports a working m3gdb right now.<br><br>And I use m3gdb all the time in my own work.<br><br>Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*.  Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until
 something newer supports at least all the same debug functions.<br><br><br>><br>>   - Jay<br>><br></div></blockquote></td></tr></table>