<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'> > Cross compiles can produce assembler<BR> <BR> <BR>It works this way today, but I don't see the point in the future.<BR>M3x86.m3 generates object files, always.<BR>It is widely wished to have C compilers output object files directly instead of assembly, and many do, but not gcc.<BR>M3C.m3 will always generate C. Though there is an analog in there in my theoretical ideas..if there was just one mode -- IntegratedObject -- then M3C.m3 would internally call quake/config to compile C to .o. Unless bootstrapping, then it would keep as C. I think "bootstrapping" isn't likely infrastructurally/consistently defined, or shouldn't be. It is up to each backend to interpret it, paired with some next-step-in-the-bootstrap-pipeline. Just because a backend "usually" generates object files, doesn't mean bootstrapping stops at assembly. It depends. On a backend-by-backend basis. I think.<BR> <BR> <BR>Anyway, I'll leave it alone and move on with more pressing/fun matters.<BR>Apparently I didn't really compile all of "cm3", but still a lot. I'll keep iterating. I'm at libm3. Hopefully I don't hit problems at each step -- that the previous testing did cover a lot. Ok either way...<BR> <BR> <BR> <BR> ..Jay<br> <BR><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">CC: hosking@cs.purdue.edu; m3devel@elegosoft.com<br>From: antony.hosking@gmail.com<br>Subject: Re: [M3devel] backend mode integratedassembly<br>Date: Fri, 14 Sep 2012 19:40:43 -0400<br>To: jay.krell@cornell.edu<br><br><div><br><br>Sent from my iPhone</div><div><br>On Sep 14, 2012, at 18:44, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><div></div><blockquote><div>
<style><!--
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:12pt;font-family:Calibri;}
--></style>
<div dir="ltr">It somewhat gets in the way of reading/writing the code.<br>It bit-rots.<br> <br> <br>I kind of think this area needs a bit of a reworking.<br>There could/should be more code sharing. (Or maybe actually less infrastructure.)<br> <br> <br>If anyone really did write an integrated backend that produced assembly, they could/should then have that backend go ahead and have that backend call the assembler. Maybe.<br></div></div></blockquote><div><br></div><div>Cross compiles can produce assembler. So maybe worth keeping.</div><br><blockquote><div><div dir="ltr"> <br> <br>The -boot and -keep flags should perhaps be passed on the backend.<br> <br> <br>By this measure, I might as well just call my C backend "IntegratedObject", and have it call out to quake/config to run the C compiler -- heck, esp. if RunCC was made part of Builder.i3 instead of just Builder.m3 (or passed down as a function pointer -- I guess otherwise there might be a circular dependency).<br></div></div></blockquote><div><br></div><div>I think using the tool chain is fine. It gives flexibility and a format humans can read from one to the next. </div><br><blockquote><div><div dir="ltr"> <br> <br>I nearly did that.<br>I guess I was too lazy to teach my backend how to call out to the C compiler via quake, rather than reuse Builder.m3.<br> <br> <br>That is...I'm not sure there should be any modes at all.<br>There should be "types" which is just which Interface.T implementation of M3CG to instantiate.<br>They would all be "IntegratedObject".<br>C backend would like I said, generate C itself, then call out to quake/compile_c.<br>(It could almost just be "cc foo.c -o foo.o", but that isn't quite adequate/portable).<br> <br> <br>IntegratedAssembly would generate assemlby, then call out to quake/assemble, if it doesn't know otherwise.<br> <br> <br>m3cc/m3back/m3cg would be a very thin wrapper over m3cg.<br>Everything but open/close would call down to m3cg_binwr.<br>At close time, it would call out to quake/config to run the assembler, if not bootstrapping.<br> <br> <br>I like it -- no modes, just specific types. They would all be treated as "IntegratedObject".<br> <br> <br>Question would how much sharing/commonality is there really.<br> <br> <br>I guess it doesn't matter much...<br> <br> <br>I guess "externals" backends are convenient, to test?<br>So going though m3cg_binwr is nice?<br>So then you get commonality there?<br> <br> <br>I'm still not sure that belongs in Builder.m3, vs. "M3CG_ExternalViaBinWr".<br>Which could know about the boot/keep flags and keep the .mc files..<br> <br> <br> - Jay<br><br> <br><div><div id="ecxSkyDrivePlaceholder"></div><hr id="ecxstopSpelling">Subject: Re: [M3devel] backend mode integratedassembly<br>From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Fri, 14 Sep 2012 17:07:28 -0400<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><br>
<br><div><div>On Sep 14, 2012, at 4:24 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div style="font: 12pt/normal Calibri; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; orphans: 2; widows: 2; font-size-adjust: none; font-stretch: normal;" class="ecxhmmessage"><div dir="ltr">There is a backend mode for an integrated backend that generates assembly.<div>This is dead code, right?</div><div>Remove it?<br></div><div><* ASSERT FALSE *> (but then I get warnings about unreachable code -- comment it out?</div></div></div></blockquote><div><br></div><div>There is nothing to be gained from removing it.</div><div>Maybe someone will want to experiment/resurrect.</div><div><br></div></div></div> </div>
</div></blockquote></div> </div></body>
</html>