<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'><div>I agree development never ends.</div><div>One should always keep in mind active development and not treat it as rare/unusual.</div><div><br></div><div><br></div><div>The way to get assembly output, I claim, is to fiddle with the config file.</div><div><br></div><div><br></div><div>For example, add -S or -s on the C compiler command line.</div><div><br></div><div><br></div><div>I don't believe it is ever useful/required to output assembly for the entire tree</div><div>using a C compiler or LLVM.</div><div><br></div><div><br></div><div>It is only needed very temporarily/modally for focused debugging.</div><div>Even if development never ends.</div><div><br></div><div><br></div><div>Unless maybe you are analysing picking up a new LLVM or such?</div><div><br></div><div><br></div><div>You usually trust the C compiler and LLVM to translate correctly</div><div>from your output. Usually you only care to look at your output.</div><div>Therefore -keep.</div><div><br></div><div><br></div><div>I can be flexible on this.</div><div>Still, it doesn't require a mode I Think.</div><div><br></div><div><br></div><div>Yes I have about same meaning of "internal" as you.</div><div>I guess there are multiple variables: </div><div> separate process? </div><div> separate .so/dll? </div><div> output the cm3cg files? </div><div> </div><div> </div><div> Up until now, they have always coincided.</div><div> In terms of the builder though, it would not likely</div><div> do anything different for static linking vs. dynamic linking of LLVM.</div><div> It should still just make the same function calls.</div><div> Unless maybe you want to use dlopen/dlsym?</div><div> Which is really yet another mode "dynamic dynamic".</div><div> </div><div> </div><div> </div><div>I think it is really just if the cm3cg files are output.</div><div> </div><div> </div><div><br></div><div> </div><div>I should see if I can eliminate the C mode, in order to "prove"</div><div>I'm not being hypocritical here. I think it was just for easier</div><div>access to the RunCC or such. I'll try to pass that address to</div><div>the C backend and then go back to InternalObject mode..</div><div><br></div><div><br></div><div>If C mode is just InternalObject, then probably LLVM should be too.</div><div>Again, builder should just decide to produce the IR files or not.</div><div>The other decisions are other variables that Builder doesn't care about.</div><div>One does have to instantiate the right backend somewhere.</div><div> </div><div> </div><div>It isn't a huge deal though. Builder can temporarily be a mess and we can</div><div>clean it up later.</div><div><br></div><div><br></div><div> > Actually, I'd also like to be able to set it up so m3cgcat gets</div><div> > run on .mc/.mc files and llvm-dis on .mb/.ib files, by cm3. It</div><div> > would just save a couple of manual steps that I am typing over</div><div> > and over, slowing down the debug process.</div><div> </div><div><br></div><div> I think this is just a matter of a few lines of quake.</div><div> </div><div> Can you look at what I did for m3cgcat and the C mode?</div><div> </div><div>Here:</div><div><br></div><div><br></div><div>cm3cg.common:</div><div><br></div><div>if not defined("USE_C_BACKEND_VIA_M3CGCAT")</div><div> USE_C_BACKEND_VIA_M3CGCAT = FALSE</div><div>end</div><div><br></div><div>and then:</div><div><br></div><div><br></div><div>if USE_C_BACKEND_VIA_M3CGCAT</div><div>M3_BACKEND_MODE = "ExternalObject"</div><div><br></div><div>proc m3_backend(source, object, optimize, debug) is</div><div> ret_code = try_exec("m3cgcat", "-in-binary:" & source, "-out-c:" & source & ".c")</div><div> if not equal(ret_code, 0)</div><div> return ret_code</div><div> end</div><div> return compile_c(source & ".c", object, [ ], FALSE, TRUE)</div><div>end</div><div>end</div><div><br></div><div><br></div><div>I don't remember any problems with this, just that it is slower to output the files.</div><div><br></div><div><br></div><div>If you wanted to see the C compiler output, here you'd add -S or -s or -FA or such.</div><div>No need to change the mode.</div><div>There is something subtle here I'm not explaining well, how this is useful</div><div>but doesn't need to be automated, because it is used rarely and only at small scale.</div><div><br></div><div><br></div><div>Like, I had no need for a CToAssembly mode.</div><div><br></div><div><br></div><div>Ultimately "internal" modes are probably always faster, and the draw is strong</div><div>for that reason. The C backend is slow enough w/o "external" making it slower.</div><div><br></div><div><br></div><div> - Jay</div><br><br><br><br><div>> Date: Sat, 12 Sep 2015 19:13:27 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] LLVM builder modes Int/Ext/StAlone<br>> <br>> My inference has been that "internal" means the whole compilation job<br>> is done by code linked in (not necessarily statically) to cm3, e.g.,<br>> using the integrated x86 backend. "external" means there are one or<br>> more separate executables to run after the front end, e.g., m3cc<br>> and as, or m3llvm, llc, asm, etc.<br>> <br>> I definitely want the possibility of keeping assembly form for development work,<br>> even when 'as' is run. And we should assume that occasional development work<br>> will continue forever. Disassembling object code will lose sometimes very<br>> useful information, compared to keeping assembly as originally generated as<br>> a side output.<br>> <br>> Actually, I'd also like to be able to set it up so m3cgcat gets<br>> run on .mc/.mc files and llvm-dis on .mb/.ib files, by cm3. It<br>> would just save a couple of manual steps that I am typing over<br>> and over, slowing down the debug process.<br>> <br>> On 09/12/2015 06:50 PM, Jay K wrote:<br>> > Those comments were from me, since I went through<br>> > and 1) added the C mode 2) tried to clean up what<br>> > I percieve as rather messy, and still messy.<br>> ><br>> ><br>> > You helped my vocabulary here -- it should be "cartesian factored".<br>> > Rather than every "product" be its own case.<br>> ><br>> ><br>> > I moved it toward that, but it still confusing.<br>> ><br>> ><br>> > Basically you want a set of available steps, and<br>> > then just sequence them, possibly omitting some of them.<br>> ><br>> ><br>> > I can see how you might have roughly 10 choices,<br>> > depending on if you are outputing bitcode or LLVM assembly<br>> > or building LLVM data structures, and linking to LLVM or not,<br>> > and LLVM is producing assembly or object files.<br>> ><br>> ><br>> > I would suggest that LLVM produing assembly is not a useful choice.<br>> > Remove that from the matrix.<br>> > Have it produce object files if you can.<br>> > For debugging, you can fiddle with the switches or dump the files<br>> > afterward.<br>> ><br>> ><br>> > If you are producing cm3cg IR files like for m3cc, likely you don't need builder support.<br>> > You can use the "external object" mode plus config file stuff.<br>> > I started that way for C and didn't change the builder initially.<br>> > But it was slower. I don't remember why i needed builder support,<br>> > vs. the existing "internal object" mode,<br>> > maybe to more easily reuse the existing support for compiling C.<br>> > My mode is kind of "internal plus run some quake code".<br>> > I guess I could setup linkage so the C backend could call the quake<br>> > code w/o the builder knowing about it.<br>> > Maybe I should try that, so we can get back to the original set of modes.<br>> ><br>> ><br>> > Basically "external" means "produce cm3cg IR files".<br>> > "Internal" means don't produce them.<br>> > And then "assembly" means "run assembler after backend"<br>> > and "object" means don't run assembler because we already have objects.<br>> ><br>> ><br>> > Whether or not the m3cg IR files are being converted to C and then objects<br>> > or gcc internals and then objects, or LLVM internals and then objects,<br>> > the builder doesn't need to know or act differently.<br>> > It just runs the quake function m3_backend or such, and it decides,<br>> > via a separate factor from mode to run llvm or cm3cg on the IR file.<br>> ><br>> ><br>> > Basically, let's say we have n different external backends producing<br>> > object files. That doesn't imply any new modes. But some other variable<br>> > that affects the quake code that runs cm3cg.<br>> ><br>> ><br>> > Thank you for the confirmation as to which mode you are using.<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> ><br>> > > Date: Fri, 11 Sep 2015 15:13:43 -0500<br>> > > From: rodney_bates@lcwb.coop<br>> > > To: m3devel@elegosoft.com<br>> > > Subject: Re: [M3devel] LLVM builder modes Int/Ext/StAlone<br>> > ><br>> > > Yes, I put in all the modes I thought of while working in there, as it's a lot easier<br>> > > to do it when you are familiar with the code than refamiliarize later. There were<br>> > > already some with comments like "No such back end". Only the StAloneLlvm ones<br>> > > have an actual back end. The others are intended for modes that link in at least<br>> > > some of llvm into cm3. As discussed, we may not want to do this.<br>> > ><br>> > > The only mode I have tried is StAloneLlvmAsm. This is running to compile completion<br>> > > on small examples and passing a good few of the compiler tests. Right now, I am working<br>> > > on the ones that pass using m3cc and fail using m3llvm, before trying to build the real code.<br>> > ><br>> > > On 09/10/2015 08:53 PM, Jay K wrote:<br>> > > > Here is what I get: some "crash", some "fail", some get the file format mixed up, some work!<br>> > > > 6 modes. 4 crash, 1 appears to work, 1 appears close<br>> > > ><br>> > > ><br>> > > > jair:m3core jay$ for a in \<br>> > > > IntLlvmObj \<br>> > > > IntLlvmAsm \<br>> > > > ExtLlvmObj \<br>> > > > ExtLlvmAsm \<br>> > > > StAloneLlvmObj \<br>> > > > StAloneLlvmAsm; \<br>> > > ><br>> > > > do rm AMD64_DARWIN/RT0.io ; echo $a;cm3 -DM3_BACKEND_MODE=$a -keep -commands; done<br>> > > ><br>> > > > IntLlvmObj<br>> > > > *** runtime error:<br>> > > > *** Segmentation violation - possible attempt to dereference NIL<br>> > > > *** pc = 0x1030edca3 = set_error_handler + 0x5b in ../src/M3CG.m3<br>> > > > ***<br>> > > ><br>> > > > IntLlvmAsm<br>> > > > *** runtime error:<br>> > > > *** Segmentation violation - possible attempt to dereference NIL<br>> > > > ***<br>> > > ><br>> > > > ExtLlvmObj<br>> > > > *** runtime error:<br>> > > > *** Segmentation violation - possible attempt to dereference NIL<br>> > > > *** pc = 0x10e8b0ca3 = set_error_handler + 0x5b in ../src/M3CG.m3<br>> > > ><br>> > > > ExtLlvmAsm<br>> > > > *** runtime error:<br>> > > > *** Segmentation violation - possible attempt to dereference NIL<br>> > > ><br>> > > > StAloneLlvmObj<br>> > > > m3llvm -b -d -o RT0.ib RT0.ic<br>> > > > llc -disable-fp-elim -filetype=obj -relocation-model=pic RT0.ib -o RT0.io<br>> > > ><br>> > > > => success?<br>> > > ><br>> > > > except for:<br>> > > > error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: RT0.io is not an object file (not allowed in a library)<br>> > > ><br>> > > ><br>> > > > StAloneLlvmAsm<br>> > > > close, maybe just a config problem<br>> > > > m3llvm -b -d -o RT0.ib RT0.ic<br>> > > > llc -disable-fp-elim -filetype=asm -relocation-model=pic RT0.ib -o RT0.is<br>> > > > fg++ -m64 -arch x86_64 -c -x assembler RT0.is -o RT0.io<br>> > > > RT0.is:5:2: error: unknown directive<br>> > > ><br>> > > ><br>> > > > I assume we should ignore Int and Ext and focus on StAlone for now.<br>> > > ><br>> > > ><br>> > > > - Jay<br>> > > ><br>> > > ><br>> > > > _______________________________________________<br>> > > > M3devel mailing list<br>> > > > M3devel@elegosoft.com<br>> > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > > ><br>> > ><br>> > > --<br>> > > Rodney Bates<br>> > > rodney.m.bates@acm.org<br>> > > _______________________________________________<br>> > > M3devel mailing list<br>> > > M3devel@elegosoft.com<br>> > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> ><br>> ><br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>