<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Emulating the gcc-based approach is not good.<div><br></div><div><br><div>We have four modes currently:</div><div>ExternalAssembly, ExternalObject, IntegratedAssembly, IntegratedObject</div><div>(They have numbers like 0, 1, 2, 3, but I gave them sensible names too.)</div><div><br></div><div><br></div><div> NT/x86 uses IntegratedObject </div><div> gcc/m3cg uses ExternalAssembly </div><div> "External" means "produce .mc files and run the quake function m3back()" </div><div> "Object" means we got .o files and are "done". "Assembly" means cm3/Builder should then use quake or whatever to run the assembler.</div><div><br></div><div><br></div><div> currently I am using ExternalObject; via config file changes where the quake function m3back calls m3cgcat to go .mc to .c, and then m3back calls compile_c to go .c to .o.</div><div><br></div><div><br></div><div>"External" anything is convenient for development and testing, bad for performance.</div><div> It writes and reads the .mc files. </div><div> Besides development/testing, it also is used for licensing reasons -- communication through files instead of "linking" code.</div><div><br></div><div><br></div><div>"Object" is preferable to "Assembly" in this case because going from .c to .o is "easier" than going from .c to .s..sort of. Due to the requirements of gcc/m3cg, we do already have fully developed/configured ability to run the assembler.. so ease/portability are kind of moot -- cc -c foo.c -o bar.o isn't actually portable enough (e.g. it doesn't work for Darwin/amd64), we still have to be somewhat expert in C compiler invocation/flags, and we are. But some C compilers do output .o files directly without going through an assembler, so it should be faster. e.g. NT and I believe clang, Sun CC, that is, everything but gcc. So "Object" is faster than "Assembly".</div><div><br></div><div><br></div><div>So that leaves us with IntegratedObject.</div><div>M3C.m3 will have to interact with quake.</div><div><br></div><div><br></div><div>OR I can introduce "IntegratedC". Leave M3C ignorant of quake and leave it up to cm3/Builder to compile the output. (Still skipping the .mc files and m3cgcat).</div><div><br></div><div><br></div><div>It shouldn't be a big deal either way.</div><div><br></div><div><br></div><div>cm3/Builder still has to new up a different backend.</div><div><br></div><div><br></div><div>For LLVM you'll likely follow a similar course.</div><div>"External" is convenient for development and testing, but slower.</div><div>"Object" and "Assembly" are probably both options and you can probably go "directly" to "Object", skipping "Assembly".</div><div>You won't need to invoke a C compiler or assembler, and IntegratedObject will work more directly for you. Still/again you'll have to teach cm3/Builder to new up your backend, instead of the one Integrated backend.</div><div><br></div><div><br></div><div><br></div><div> - Jay</div><div><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: hosking@cs.purdue.edu<br>Date: Fri, 12 Oct 2012 13:23:59 -0400<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com; antony.hosking@gmail.com<br>Subject: Re: [M3devel] C backend -- mode or call quake?<br><br>Why not treat it like the current gcc-based approach? The builder generates C and quake invokes the C compiler. Just like for gcc: the builder generates .mc and quake invokes m3cgc1. I will want much the same for LLVM. The builder will generate LLVM IR binaries and the LLVM tools will do the rest (invoked from quake). This makes it relatively easy to do cross builds from quake.<div><div>
<br><div><div>On Oct 12, 2012, at 12:50 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;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"><div dir="ltr">Clarification: it is "integrated" either way -- no production of .mc files.<div>Just that cm3/builder would know that "IntegratedC" produce a .c file (or perhaps is writing to a pipe) and to then run the C compiler. Vs. pushing that into the backend itself and leaving cm3/builder with "IntegratedObject" that it already knows how to deal with. Either way cm3/builder has to change.</div><div><br></div><div><br></div><div>Currently I'm going through config-only changes.</div><div><br></div><div><br></div><div> - Jay</div><div><br><br><div><div id="ecxSkyDrivePlaceholder"></div><hr id="ecxstopSpelling">CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>From: <a href="mailto:antony.hosking@gmail.com">antony.hosking@gmail.com</a><br>Subject: Re: [M3devel] C backend -- mode or call quake?<br>Date: Fri, 12 Oct 2012 09:12:53 -0400<br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>I vote for integrated. <br><br>Sent from my iPhone</div><div><br>On Oct 12, 2012, at 0:43, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div dir="ltr">ok..so..I think time to make this decision and implement it.<div><br></div><div> - add a "mode" for C and deal with it in Builder.m3</div><div> I implemented and tested that and presented the diff a few weeks ago</div><div> It is reasonable, simple, works..but it isn't strictly needed.</div><div><br></div><div>or</div><div><br></div><div>- use IntegratedObject and have the C backend call the C compiler "itself" (via the</div><div>existing quake/config files)</div><div>I can go ahead and implement that.</div><div><br></div><div><br></div><div>Either way, cm3 likely must know about the C backend.</div><div><span style="font-size:12pt">It at least has to "new" it, and maybe pass down function pointers for running</span></div><div><span style="font-size:12pt">the C compiler -- or maybe M3C can get the pointers itself.</span></div><div><span style="font-size:12pt"><br></span></div><div>Or I can put this off a bit longer and improve the generated C...</div><div>Using "integrated" saves us from writing and reading back the .mc files.</div><div>More efficient.</div><div><br></div><div><br></div><div><span style="font-size:12pt"> - Jay</span></div></div></blockquote></div></div></div></div></blockquote></div><br></div></div></div></div></div> </div></body>
</html>