[M3devel] elimining builder.C mode (instead IntegratedObject and another boolean)

[Jay K]

I suppose it is more convenient to have the C mode than I say -- it alsoputs the bootstrap vs. non-bootstrap decision in a convienent place,and the management of keep_files, and the deleting of temporary files.

All that logic can be easily moved elsewhere, or not.

But then we have like 6 LLVM modes.I set a bad example, and now it is even worse.

Arguably we only need 2 modes -- internal and external.Any backend, internal or example, that produces assembly, canrun the assembler itself -- we could expose that in M3CG justlike I want to expose running the C compiler.

I like it.

Or even just one mode -- call the backend.We just need to provide in M3CG_Ops a function to write out the .mc files,that the backend can call if it needs it. i.e. for the backend call into quake/config.Each backend can put together its specific sequence.There is some commonality currently factored into Builder, but not reallymuch and it is a mess.

I'm undecided at the moment.

 - Jay


From: jay.krell at cornell.edu
To: hosking at purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] elimining builder.C mode (instead IntegratedObject and another boolean)
Date: Mon, 21 Sep 2015 02:58:42 +0000




I believe we really only need 4 modes.Internal or Externalproduces object or assembly
All the other modes are unnecessary.I will do my part and eliminate the one I added.Hopefully leading the way to eliminating all the LLVM modes.

C backend certainly supported, I just didn't expose it in the ideal way.

 - Jay



Subject: Re: [M3devel] elimining builder.C mode (instead IntegratedObject and another boolean)
From: hosking at purdue.edu
Date: Mon, 21 Sep 2015 12:49:19 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

What is the benefit of doing this?  It would seem to me to be nicer to retain the existing modes. 

Sent from my iPhone
On Sep 21, 2015, at 12:22 PM, Jay K <jay.krell at cornell.edu> wrote:




I want remove the C mode from the builder and just use IntegratedObject.The goal is to expose Builder.RunCC to M3C.    Something like:     add some data to MC3CG_Op.TI wouldn't bother with "set" functions.  I'm also not making them module global -- this could be globals in M3C.But I want to preserve the illusion that things can be easily made multi-threaded (m3front structuring very much to the contrary...) 
The data will be: declare Builder.State <: REFANY in Builder.i3   M3CG_Ops should get    RunCCState: Builder.State;    OR   BuilderState: Builder.State; 
  keep_files: BOOLEAN;    PROCEDURE RunCC (s: State;  source, object: TEXT;  debug, optimize: BOOLEAN;                  include_path: Arg.List): BOOLEAN (* Success. *);  or possibly:   PROCEDURE RunCC (s: State;  source, object: TEXT): BOOLEAN (* Success. *);    or possibly:   PROCEDURE RunCC (s: State;  source: TEXT; u: M3Unit.T): BOOLEAN (* Success. *)     include_path isn't really needed here.
also:  M3Backend.PROCEDURE Open (target: Wr.T;  target_name: TEXT;  backend_mode: M3BackendMode_t): M3CG.T;
should be changed to:  PROCEDURE Open (m3file: TEXT; target: Wr.T;  target_name: TEXT;  backend_mode: M3BackendMode_t): M3CG.T;

ok?
   - Jay
 		 	   		  
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150921/4b039b5c/attachment-0002.html>