[M3devel] backend mode integratedassembly

[Jay K]

 > Cross compiles can produce assembler  It works this way today, but I don't see the point in the future.M3x86.m3 generates object files, always.It is widely wished to have C compilers output object files directly instead of assembly, and many do, but not gcc.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.  Anyway, I'll leave it alone and move on with more pressing/fun matters.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...    ..Jay
 CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
From: antony.hosking at gmail.com
Subject: Re: [M3devel] backend mode integratedassembly
Date: Fri, 14 Sep 2012 19:40:43 -0400
To: jay.krell at cornell.edu



Sent from my iPhone
On Sep 14, 2012, at 18:44, Jay K <jay.krell at cornell.edu> wrote:




It somewhat gets in the way of reading/writing the code.
It bit-rots.
 
 
I kind of think this area needs a bit of a reworking.
There could/should be more code sharing. (Or maybe actually less infrastructure.)
 
 
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.

Cross compiles can produce assembler. So maybe worth keeping.
 
 
The -boot and -keep flags should perhaps be passed on the backend.
 
 
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).

I think using the tool chain is fine. It gives flexibility and a format humans can read from one to the next. 
 
 
I nearly did that.
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.
 
 
That is...I'm not sure there should be any modes at all.
There should be "types" which is just which Interface.T implementation of M3CG to instantiate.
They would all be "IntegratedObject".
C backend would like I said, generate C itself, then call out to quake/compile_c.
(It could almost just be "cc foo.c -o foo.o", but that isn't quite adequate/portable).
 
 
IntegratedAssembly would generate assemlby, then call out to quake/assemble, if it doesn't know otherwise.
 
 
m3cc/m3back/m3cg would be a very thin wrapper over m3cg.
Everything but open/close would call down to m3cg_binwr.
At close time, it would call out to quake/config to run the assembler, if not bootstrapping.
 
 
I like it -- no modes, just specific types. They would all be treated as "IntegratedObject".
 
 
Question would how much sharing/commonality is there really.
 
 
I guess it doesn't matter much...
 
 
I guess "externals" backends are convenient, to test?
So going though m3cg_binwr is nice?
So then you get commonality there?
 
 
I'm still not sure that belongs in Builder.m3, vs. "M3CG_ExternalViaBinWr".
Which could know about the boot/keep flags and keep the .mc files..
 
 
 - Jay

 
Subject: Re: [M3devel] backend mode integratedassembly
From: hosking at cs.purdue.edu
Date: Fri, 14 Sep 2012 17:07:28 -0400
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu




On Sep 14, 2012, at 4:24 PM, Jay K <jay.krell at cornell.edu> wrote:There is a backend mode for an integrated backend that generates assembly.This is dead code, right?Remove it?
<* ASSERT FALSE *> (but then I get warnings about unreachable code -- comment it out?
There is nothing to be gained from removing it.Maybe someone will want to experiment/resurrect.
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120914/b6fe3913/attachment-0002.html>