<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'><div>Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends.</div><div><br></div><div><br>"external" is good for developing backends. You can "snapshot" the state of things<br>slightly into the pipeline and then just iterate on later parts.</div><div><br></div><div><br>At the cost of having all the serialization code.</div><div><br></div><div><br>"integrated" is usually preferable for performance, for users.</div><div><br></div><div><br>E.g. NTx86 backend has been sitting in there for decades unused by half the users.</div><div><br></div><div><br>Having extra backends sitting in there unused is ok.<br>Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho.<br>Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't.</div><div><br></div><div><br>Everything is demand paged so there is cost to distribute over the network<br>and copy around, but at runtime, the pages just sit mostly cold on disk.</div><div><br></div><div><br>One difficulty though is the need to have and build the LLVM code.<br>For that reason, delayload-dynamically-linked might be preferable.<br>It depends on how small/easy-to-build LLVM is.</div><div><br></div><div><br> I guess LLVM provides more choices than before. <br> In order of efficiency and inverse order of debuggability: <br> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. <br> 2 We could write out LLVM bytes and run an executable. <br> 3 We could write out LLVM text and run an executable. </div><div><br></div><div><br> > My personal preference would be to only have one default target statically compiled in </div><div><br></div><div> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR.<br> And I don't think LLVM works that way, does it?</div><div><br></div><div> I like one compiler to have all targets and just select with a command line switch.</div><div><br></div><div> I don't like how hard it is to acquire various cross-toolschains.<br> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline,<br> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a".</div><div><br></div><div><br> binutils at least has this "all" notion reasonably well working now I believe.</div><div><br></div><div><br></div><div><br></div><div>There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all.</div><div>And the largely wasted bloat.</div><div><br></div><div><br></div><div>Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets.</div><div>There is work to do there..not easy..and no progress lately.</div><div>Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding...</div><div><br></div><div><br></div><div><br> - Jay<br><br><br><br><br></div><div>> Date: Thu, 21 May 2015 20:13:18 +0200<br>> From: estellnb@elstel.org<br>> To: rodney.m.bates@acm.org; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] How to integrate llvm into cm3<br>> <br>> Am 21.05.15 um 19:24 schrieb Rodney M. Bates:<br>> ><br>> > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into<br>> > the cm3 executable would be faster compiling--one fewer time per <br>> > interface<br>> > or module for the OS to create a process and run an executable. But it<br>> > would also entail linking in this code, along with some of llvm's <br>> > infrastructure,<br>> > into cm3, making its executable bigger, with code that might not be <br>> > executed<br>> > at all, when a different backend is used. We already have the x86 <br>> > integrated<br>> > backend and the C backend linked in to cm3, whether used or not.<br>> ><br>> > Anybody have thoughts on this? I suppose it could be set up to be fairly<br>> > easily changed either way too.<br>> ><br>> <br>> Why not put each backend into a shared library and load it dynamically?<br>> Are there still problems with shared libraries for some build targets?<br>> On the other hand having cm3-IR handy and being able to translate<br>> cm3-IR by an executable like m3cc into any desired target has proven<br>> to be very handy for debugging as well as chocking the Modula-3<br>> compiler on a new platform.<br>> My personal preference would be to only have one default target<br>> statically compiled in namely that on for cm3-IR and load all other<br>> targets by a shared libarary dynamically. If that should fail for some<br>> reason one can still use m3cc or one of its counterparts to<br>> accomplish the translation process.<br>> <br>> Elmar<br>> <br>> <br>> <br>> <br>> <br>> <br></div> </div></body>
</html>