<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> Sorry, my life has really changed and I have hardly any time now..<br> I still hope to come back. <br><br><br><br>The C backend works quite well.<br>I was able to cross-to and self-world-build many platforms.<br>Including bring up new platform: AMD64_NT.<br>There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.<br>jmpbuf remains a platform-specificity in the frontend.<br><br><br> I believe we had mostly good experience with Linux/arm and maybe Dragonfly? <br> Not sure.<br><br><br> Going through C source and C compiler is noticable slower. <br><br><br>The "levelness" of the output is near what I was aiming for, for the first go.<br> - records all have fields; you can view them in standard debuggers -- good! <br> This took me a while but I got there. <br> - but globals are not viewable -- all offsets into particular records <br> - all locals/parameters get numbers on the end to disambiguate<br> from "nearby" name clashes, though usually it isn't needed;<br> this is near the top of the things to fix<br><br><br>The "levelness" is still low in that the word size and posix vs. NT is baked in.<br>If you want "one source release", you really need to make about 6 currently:<br> posix 32bit little endian (many systems) <br> posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) <br> posix 64bit little endian (many systems) <br> posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin) <br> nt 32bit little endian <br> nt 64bit little endian <br><br><br> There is one recent outstanding bug report where the generated C is invalid. <br><br><br> Besides jmpbuf, I'd like to see endianness factored out.<br> There is approx one instance of endian specificity in the frontend<br> I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.<br><br><br>I'd also like to see exception handling optionally implemented on top of C++ exception<br>handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).<br><br><br>For a release though, most of this isn't needed.<br>Mainly: fix the one bug, decide if performance and debugability is adequate.<br><br><br> - Jay<br><br><br><br><div>> From: hosking@cs.purdue.edu<br>> Date: Tue, 27 May 2014 12:49:12 -0400<br>> To: adacore@marino.st; jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com; bruce.axtens@gmail.com<br>> Subject: Re: [M3devel] Status of CM3<br>> <br>> Jay might comment on C backend status for those platforms.<br>> <br>> On May 27, 2014, at 11:40 AM, John Marino <adacore@marino.st> wrote:<br>> <br>> > On 5/27/2014 17:34, Dragi¹a Duriæ wrote:<br>> >> You can count on me for release engineering, Git migration. Maybe CI,<br>> >> if I have resources. Problem is - feedback is poor from core<br>> >> developers wrt Git migration. I am ready for long time now.<br>> > <br>> > <br>> > This might be a good time to remind that I've been waiting for a release<br>> > that feature C-backend support for both FreeBSD and DragonFly (new).<br>> > The version in FreeBSD ports is 4 years old, but there's not been a<br>> > release since then. The last time I was active on the list we discussed<br>> > the needs of FreeBSD and for porting M3 to DragonFly and something was<br>> > supposed to happen code-wise (and then release-wise) but I don't think<br>> > anything did in the end.<br>> > <br>> > I was extremely busy with other projects but was planning on pinging on<br>> > this topic soon anyway.<br>> > <br>> > John<br>> > <br>> > <br>> >> <br>> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner@elegosoft.com> wrote:<br>> >> <br>> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens<br>> >>> <bruce.axtens@gmail.com> wrote:<br>> >>> <br>> >>>> Dear Sir<br>> >>>> <br>> >>>> Should I assume that CM3 is alive, in palliative care or dead?<br>> >>>> The trac system is full of spam and the roadmap hasn't moved for<br>> >>>> 3 years.<br>> >>>> <br>> >>>> I had a long and fruitful relationship with Modula-2 years ago<br>> >>>> and thought that perhaps I could restart things with CM3.<br>> >>> <br>> >>> There is certainly some activity in M3 development recently,<br>> >>> though the community is rather small. The trac system has never<br>> >>> been much used by the community members; and the WWW presentation<br>> >>> and regression testing system has lacked my support, as I couldn't<br>> >>> spent any time on these topics for almost 3 years.<br>> >>> <br>> >>> You should check the m3devel mailing list for news though: <br>> >>> https://mail.elegosoft.com/pipermail/m3devel<br>> >>> <br>> >>> There has been a lot of activity at the beginning of this year; it<br>> >>> has ceased again during recent weeks.<br>> >>> <br>> >>> All CVS commits can be found here: <br>> >>> https://mail.elegosoft.com/pipermail/m3commit<br>> >>> <br>> >>> A new release is long overdue; I'm afraid I cannot do the release <br>> >>> engineering this time.<br>> >>> <br>> >>> There has been some effort on moving the CVS repositories to git; <br>> >>> I'm not sure what the status is there, too.<br>> >>> <br>> >>> Any help wrt. documentation, presentation or software is greatly <br>> >>> appreciated ;-)<br>> >>> <br>> >>> Regards,<br>> >>> <br>> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --<br>> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Gebäude 12, 13355<br>> >>> Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869<br>> >>> fax: +49 30 23 45 86 95 Geschäftsführer: Michael Diers, Olaf Wagner<br>> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719<br>> >>> | USt-IdNr: DE163214194<br>> >> <br>> <br>> <br>> <br>> Antony Hosking | Associate Professor | Computer Science | Purdue University<br>> 305 N. University Street | West Lafayette | IN 47907 | USA<br>> Mobile +1 765 427 5484<br>> <br>> <br>> <br>> <br>> <br></div> </div></body>
</html>