<html><head></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 12:16 schrieb dirk muysers:</div><br class="Apple-interchange-newline"><blockquote type="cite"><base href="x-msg://43/">
<div 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></blockquote><div><br></div><div><span class="Apple-style-span" style="font-size: 16px;">Concerning me I am a very conscientious programmer when it comes to</span></div><div><span class="Apple-style-span" style="font-size: 16px;">make a difference between long, long long and int. I only use long if my</span></div><div><span class="Apple-style-span" style="font-size: 16px;">code requires a data item to be exactly as large as a pointer (in special</span></div><div><span class="Apple-style-span" style="font-size: 16px;">cases also when it comes to tap the power of 64bit machines, f.i. that</span></div><div><span class="Apple-style-span" style="font-size: 16px;">might be either 32/64bit as a </span><span class="Apple-style-span" style="font-size: 16px; ">base type for arbitrary length integers; </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">however not without taking special provisions that will tackle the </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">difference in data size. ). Usually aligning the pointers for the next </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">structure at the beginning would also solve such an issue when it comes</span></div><div><span class="Apple-style-span" style="font-size: 16px; ">to reuse existing code where data sizes may not be changed from long </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">either to int or long long without </span><span class="Apple-style-span" style="font-size: 16px; ">special consideration. </span><span class="Apple-style-span" style="font-size: 16px; ">Those who use </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">glib f.i. additionally have a g[u]int32/64 which they can use </span><span class="Apple-style-span" style="font-size: 16px; ">instead of int </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">/ long long though that should at last never make a difference for Intel x86 </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">based systems. So when it comes to use int or long long I mostly rely</span></div><div><span class="Apple-style-span" style="font-size: 16px;">on them being either 32 or 64bit.</span></div><div><span class="Apple-style-span" style="font-size: 16px;">I know that most programmers do not care and just always use </span><span class="Apple-style-span" style="font-size: 16px; ">long </span><span class="Apple-style-span" style="font-size: 16px; ">which </span></div><div><span class="Apple-style-span" style="font-size: 16px; ">I consider to be a particularly bad practice. Even in the Linux kernel they</span></div><div><span class="Apple-style-span" style="font-size: 16px; ">have declared "typedef long time_t" instead of "typedef long long time_t"</span></div><div><span class="Apple-style-span" style="font-size: 16px; ">which will create an Y2K mess all over in 2038 for all 32bit machines still</span></div><div><span class="Apple-style-span" style="font-size: 16px; ">in use then. A somehow bad decision which needs to be changed sooner</span></div><div><span class="Apple-style-span" style="font-size: 16px; ">or later even </span><span class="Apple-style-span" style="font-size: 16px; ">without </span><span class="Apple-style-span" style="font-size: 16px; ">llvm.</span></div><div><span class="Apple-style-span" style="font-size: 16px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 16px;">Now let us think of Modula-3. I believe we had a long type for cm3 the last</span></div><div><span class="Apple-style-span" style="font-size: 16px;">time I have seen it. However an equivalent to long long which does also </span></div><div><span class="Apple-style-span" style="font-size: 16px;">exist on 32bit platforms would be an absolute requirement to not break </span></div><div><span class="Apple-style-span" style="font-size: 16px;">things for llvm! Many Thanks for notifying us about this issue, Dirk.</span></div><div><span class="Apple-style-span" style="font-size: 16px;"><br></span></div><div><span class="Apple-style-span" style="font-size: 16px;">As far as I can see a Modula-3 programmer will need a good core for</span></div><div><span class="Apple-style-span" style="font-size: 16px;">portable programming anyway as we did not even uphold a guarantee for</span></div><div><span class="Apple-style-span" style="font-size: 16px;">WIDECHAR to be either 16 or 32bit.</span></div><div><span class="Apple-style-span" style="font-size: 16px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 16px; "> </span></div><div><span class="Apple-style-span" style="font-size: 16px;"><br></span></div><div><span class="Apple-style-span" style="font-size: 16px;"><br></span></div><div><span class="Apple-style-span" style="font-size: 16px;"><br></span></div><br><blockquote type="cite"><div 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> </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></div>
</blockquote></div><br></body></html>