<div dir="ltr">I followed the m3cc design mainly because I didnt want to include the llvm<div>libs in the link for cm3. It is a c++ lib set and requires the c++ linker which if you have ever built llvm or clang leaves you wondering about that linker. I was watching it link an llvm lib once and it took over 19 seconds. In fact watching the llvm build is like watching grass grow, it takes over 2 hours on my humble laptop (core i3). They</div><div>estimate about 40 minutes on a "fast" machine. I digress.</div><div> If llvm or other library is statically linked into cm3 and its not part of the standard toolchain then we would have to ship the those libs woudnt we? We dont have the package mechanism like debian and others which will drag in dependant libraries.</div><div>At the moment we ship the sources and say build this with what youve got installed.</div><div><br></div><div>Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 22, 2015 at 10:57 AM, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><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><span class=""><div><br></div><div><br> > My personal preference would be to only have one default target statically compiled in </div><div><br></div></span><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: <a href="mailto:estellnb@elstel.org" target="_blank">estellnb@elstel.org</a><br>> To: <a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a>; <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] How to integrate llvm into cm3<div><div class="h5"><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></div> </div></div>
</blockquote></div><br></div>