<html><head><base href="x-msg://54/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 22.05.2015 um 10:48 schrieb dirk muysers:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" dir="ltr" style="font-size: 12pt; font-family: Calibri; "><div dir="ltr"><div style="font-size: 12pt; font-family: Arial; color: rgb(0, 0, 0); "><div>Personally I have a strong dislike towards LLVM.</div><div>1. You first have to compile the whole tool chain.</div><div>2. It is a monstrous blob of code, mainly on Windows.</div><div>3. Contrary to a widespread belief, It is definitely NOT platform independent.</div><div>4. It changes at every release.</div><div>5. Having built your objects, you still have to run them through a platform assembler-linker.</div></div></div></div></span></blockquote><div><br></div><div><div><font class="Apple-style-span" size="4">Is it really that bad? What about the said platform dependencies you have discovered?</font></div><div><font class="Apple-style-span" size="4">I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs,</font></div><div><font class="Apple-style-span" size="4">as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb.</font></div><div><font class="Apple-style-span" size="4">Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes.</font></div><div><font class="Apple-style-span" size="4">I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm</font></div><div><font class="Apple-style-span" size="4">if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already</font></div><div><font class="Apple-style-span" size="4">been done when Apple started to adopt llvm for its own needs.</font></div><div><font class="Apple-style-span" size="4">Concerning the code size of llvm that should not be a problem as long as it remains a separate module</font></div><div><font class="Apple-style-span" size="4">compiling into an own executable or a shared library loaded in addition to other backends at runtime.</font></div><div><font class="Apple-style-span" size="4"><br></font></div></div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" dir="ltr" style="font-size: 12pt; font-family: Calibri; "><div dir="ltr"><div style="font-size: 12pt; font-family: Arial; color: rgb(0, 0, 0); "><div style="font-size: small; text-decoration: none; font-family: Calibri; font-weight: normal; color: rgb(0, 0, 0); font-style: normal; display: inline; "><div style="font: normal normal normal 10pt/normal tahoma; "><div><font size="3" face="Arial"></font> </div><div><font size="3" face="Arial">If I still had the energy of my younger years I would try to pack the platform</font></div><div><font size="3" face="Arial">dependent part of the libraries into a dynamic load library together with a JIT</font></div><div><font size="3" face="Arial">translator (e.g. libjit) for the portable application code and have a single byte-code</font></div><div><font size="3" face="Arial">producing compiler backend.</font></div><div> </div><div style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(245, 245, 245); "><div><b>From:</b><span class="Apple-converted-space"> </span><a title="jay.krell@cornell.edu" href="mailto:jay.krell@cornell.edu">Jay K</a></div><div><b>Sent:</b><span class="Apple-converted-space"> </span>Friday, May 22, 2015 2:57 AM</div><div><b>To:</b><span class="Apple-converted-space"> </span><a title="estellnb@elstel.org" href="mailto:estellnb@elstel.org">Elmar Stellnberger</a><span class="Apple-converted-space"> </span>;<span class="Apple-converted-space"> </span><a title="rodney.m.bates@acm.org" href="mailto:rodney.m.bates@acm.org">rodney.m.bates@acm.org</a><span class="Apple-converted-space"> </span>;<span class="Apple-converted-space"> </span><a title="m3devel@elegosoft.com" href="mailto:m3devel@elegosoft.com">m3devel</a></div><div><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [M3devel] How to integrate llvm into cm3</div></div></div><div> </div></div><div style="font-size: small; text-decoration: none; font-family: Calibri; font-weight: normal; color: rgb(0, 0, 0); font-style: normal; display: inline; "><div dir="ltr"><div>Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends.</div><div> </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> </div><div><br>At the cost of having all the serialization code.</div><div> </div><div><br>"integrated" is usually preferable for performance, for users.</div><div> </div><div><br>E.g. NTx86 backend has been sitting in there for decades unused by half the users.</div><div> </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> </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> </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> </div><div><br>I guess LLVM provides more choices than before.<span class="Apple-converted-space"> </span><br>In order of efficiency and inverse order of debuggability:<span class="Apple-converted-space"> </span><br> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o.<span class="Apple-converted-space"> </span><br> 2 We could write out LLVM bytes and run an executable.<span class="Apple-converted-space"> </span><br> 3 We could write out LLVM text and run an executable.</div><div> </div><div><br>> My personal preference would be to only have one default target statically compiled in</div><div> </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> </div><div>I like one compiler to have all targets and just select with a command line switch.</div><div> </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> </div><div><br>binutils at least has this "all" notion reasonably well working now I believe.</div><div> </div><div> </div><div> </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> </div><div> </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> </div><div> </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">estellnb@elstel.org</a><br>> To: <a href="mailto:rodney.m.bates@acm.org">rodney.m.bates@acm.org</a>; <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] How to integrate llvm into cm3<br>><span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><br>> > infrastructure,<br>> > into cm3, making its executable bigger, with code that might not be<span class="Apple-converted-space"> </span><br>> > executed<br>> > at all, when a different backend is used. We already have the x86<span class="Apple-converted-space"> </span><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>><span class="Apple-converted-space"> </span><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>><span class="Apple-converted-space"> </span><br>> Elmar<br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>></div></div></div></div></div></div></span></blockquote></div><br></body></html>