<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'>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> <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> <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="SkyDrivePlaceholder"></div><hr id="stopSpelling">Subject: Re: [M3devel] backend mode integratedassembly<br>From: hosking@cs.purdue.edu<br>Date: Fri, 14 Sep 2012 17:07:28 -0400<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<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></body>
</html>