<HTML><HEAD>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></STYLE>
</HEAD>
<BODY class=hmmessage dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<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
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV style="FONT: 10pt 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: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=jay.krell@cornell.edu
href="mailto:jay.krell@cornell.edu">Jay K</A> </DIV>
<DIV><B>Sent:</B> Friday, May 22, 2015 2:57 AM</DIV>
<DIV><B>To:</B> <A title=estellnb@elstel.org
href="mailto:estellnb@elstel.org">Elmar Stellnberger</A> ; <A
title=rodney.m.bates@acm.org
href="mailto:rodney.m.bates@acm.org">rodney.m.bates@acm.org</A> ; <A
title=m3devel@elegosoft.com href="mailto:m3devel@elegosoft.com">m3devel</A>
</DIV>
<DIV><B>Subject:</B> 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: #000000; 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. <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> </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:
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></DIV></DIV></DIV></BODY></HTML>