<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'> > A) There has been no release<br><BR> <BR>There has been no release.<BR> <BR> <BR>> B) We want to convert FreeBSD to c-backend<br><BR><br>I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.<BR> <BR> <BR>Specifically, I no longer have shelves full of a myriad of computers, but I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux, OpenBSD, FreeBSD, NetBSD), I have the Solaris opencsw sparc32/sparc64/x86/amd64 machines, I have the Mac, I have Windows, I have the Elego Debian/amd64 maybe Debian/x86 machine and I tested many/all of these successfully. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't offer the thread/suspend/getcontext stuff -- something cooperative suspend will fix eventually.<BR> <BR> <BR>Adding new platforms is fairly straightforward. Far more than it used to be.<BR>You just make few scattered easy edits.<BR>My pseudo goal is to drive that down to be easier and easier.<BR>Several platforms have been relatively recently brought back or brought up or at least shown to work completely or almost to me.<BR> <BR>What remains unclear to me is the consensus decision on exactly what the switch looks like.<BR> 1) unconditionally switch all targets <BR> 2) leave it as some sort of user option <BR> 3) have new targets only supported using the C backend <BR> <BR> <BR>There are downsides to the C backend. Specifically:<BR> 1) On systems that support m3gdb, debugging is not as good as with m3gdb <BR> m3gdb is an old fork of gdb, doesn't work on all platforms (e.g. Darwin, HP-UX, NT), but does work on many. <BR> 2) Compilation is noticeably slower. <BR> 3) The output is not necessarily ABI compatible with the non-C backend. <BR> <BR> <BR>My inclination is unconditional switch to C backend for all targets that use m3cc, leave m3cc to bit-rot.<BR>Think more about the integrated backend. In reality, given more time, I'd like to extend the integrated backend to support more targets. But that so far seems beyond most of our scopes.<BR> <BR>The safe thing is user-option. But it is also confusing.<BR>Given the ABI variation, do we double all the platforms?<BR>I386_LINUX and I386_LINUX_C?<BR> <BR> <BR> And then later POSIX_32BIT_LITTLEENDIAN_C? <BR> And then later GENERIC_C? <BR> <BR>Do we switch the existing ones, and introduce I386_LINUX_M3CC?<BR> <BR> <BR> > C) There is no support for DragonFly, we want to add that<BR> <BR>This is easy.<BR><br>> D) We want to do B+C before the next release<BR> <BR>C is easy. B requires a decision/consensus.<br> <BR>Thanks,<BR> - Jay<br><br><br> <BR><div>> Date: Wed, 28 May 2014 10:41:06 +0200<br>> From: adacore@marino.st<br>> To: jay.krell@cornell.edu; hosking@cs.purdue.edu<br>> CC: m3devel@elegosoft.com; bruce.axtens@gmail.com<br>> Subject: Re: [M3devel] Status of CM3<br>> <br>> On 5/28/2014 08:20, Jay K wrote:<br>> > 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<br>> > 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<br>> > Dragonfly?<br>> > Not sure.<br>> <br>> <br>> Hi Jay,<br>> The assumptions I was working on was this:<br>> A) There has been no release<br>> B) We want to convert FreeBSD to c-backend<br>> C) There is no support for DragonFly, we want to add that<br>> D) We want to do B+C before the next release<br>> <br>> So I thought there was some build-framework stuff that needed to happen<br>> for FreeBSD and DragonFly prior to the release, otherwise we'd just have<br>> to patch it all up and we were trying to avoid needing those patches.<br>> <br>> I am not even at the point of evaluating the C-Backend.<br>> Maybe if there was a release candidate then I could figure out what's<br>> missing a provide patches.<br>> <br>> At the very, very least we could have CM3 on github and build from a<br>> specific tag. I am not wild about that, but it's better than what's<br>> available now. (FreeBSD ports can build straight from github although<br>> it's not really encouraged)<br>> <br>> So if for no other reason, I'd like to see CM3 migrate to github ASAP.<br>> <br>> Regards,<br>> John<br></div> </div></body>
</html>