<HTML><HEAD><BASE href="x-msg://43/"></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"
dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV><FONT face=Calibri><FONT style="FONT-SIZE: 13.6pt">>> What about the
said platform dependencies you have discovered?</FONT></FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Not me (I never seriously considered using it), but many
people on the llvm</FONT></DIV>
<DIV><FONT face=Calibri>forums pointed to the fact. One example
among</FONT></DIV>
<DIV><FONT face=Calibri>many:</FONT></DIV>
<DIV><BR>Does your C code ever use the 'long' type? If so, the LLVM IR will
be<BR>different depending on whether it's targeting linux-32 or linux-64.
Do<BR>you ever use size_t? Same problem. Do you ever use a union
containing<BR>both pointers and integers? See above. In principle, it's possible
to<BR>write platform-independent IR, or even C code that compiles
to<BR>platform-independent IR. In practice, especially if you include
any<BR>system headers, it's remarkably hard.</DIV>
<DIV>(Jeffrey Yasskin <A title="[LLVMdev] LLVM for heterogenous platforms"
style='href: "mailto:llvmdev%40cs.uiuc.edu?Subject=%5BLLVMdev%5D%20LLVM%20for%20heterogenous%20platforms&In-Reply-To=20100303154221.46540%40gmx.net"'>jyasskin
at google.com) </A></DIV>
<DIV> </DIV>
<DIV>And then, besides the IR proper, there is that steadily increasing</DIV>
<DIV>legion of intrinsics.</DIV>
<DIV> </DIV>
<DIV>Unless you translate C-like code and build upon the existing
technical</DIV>
<DIV>LLVM heritage, <EM>je vous souhaite bien du plaisir</EM> as the French
say...</DIV>
<DIV><STRONG><FONT face="Times New Roman"></FONT></STRONG> </DIV>
<DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'><FONT
size=3 face=Arial></FONT></DIV>
<DIV style="FONT: 10pt tahoma">
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=estellnb@elstel.org
href="mailto:estellnb@elstel.org">Elmar Stellnberger</A> </DIV>
<DIV><B>Sent:</B> Friday, May 22, 2015 11:49 AM</DIV>
<DIV><B>To:</B> <A title=dmuysers@hotmail.com
href="mailto:dmuysers@hotmail.com">dirk muysers</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> </DIV>
<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="WHITE-SPACE: normal; WORD-SPACING: 0px; BORDER-COLLAPSE: separate; TEXT-TRANSFORM: none; FONT: medium helvetica; ORPHANS: 2; WIDOWS: 2; LETTER-SPACING: normal; TEXT-INDENT: 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">
<DIV class=hmmessage style="FONT-SIZE: 12pt; FONT-FAMILY: calibri" dir=ltr>
<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
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: 10pt tahoma">
<DIV><FONT size=3
face=Arial></FONT> </DIV></DIV></DIV></DIV></DIV></DIV></SPAN></BLOCKQUOTE>
<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> </DIV><BR>
<BLOCKQUOTE type="cite"><SPAN class=Apple-style-span
style="WHITE-SPACE: normal; WORD-SPACING: 0px; BORDER-COLLAPSE: separate; TEXT-TRANSFORM: none; FONT: medium helvetica; ORPHANS: 2; WIDOWS: 2; LETTER-SPACING: normal; TEXT-INDENT: 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">
<DIV class=hmmessage style="FONT-SIZE: 12pt; FONT-FAMILY: calibri" dir=ltr>
<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: 10pt tahoma">
<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-COLOR: rgb(245,245,245); background-origin: initial; background-clip: initial">
<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>
<DIV> </DIV></DIV></DIV></DIV></BODY></HTML>