[M3devel] Compiler upgrade broken in Hudson CI

[Daniel Alejandro Benavides D.]

Hi all:
Gcc support is becoming harder and harder to get not here precisely in gcc camp.
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).
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.
Kind of supporting 
Thanks in advance

--- El mié, 6/2/13, Coleburn, Randy <rcolebur at SCIRES.COM> escribió:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: Re: [M3devel] Compiler upgrade broken in Hudson CI
Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
Fecha: miércoles, 6 de febrero, 2013 18:13

I concur with Rodney, we must preserve the m3gdb capability and the backends that support it!
--Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Wednesday, February 06, 2013 12:25 PM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI



On 02/05/2013 02:28 AM, Jay K wrote:
> I will fix it, but I do desire to drop the old backend entirely.
> What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded.
> I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms.
>


I am not sure what is happening here, but it is making me very nervous with talk of removing backends.

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.

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.

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
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.

And I use m3gdb all the time in my own work.

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.


>
>   - Jay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130207/d8394452/attachment-0002.html>