On Wed, 2008-07-09 at 16:35 -0400, Swaroop Sridhar wrote: > Jonathan S. Shapiro wrote: > > The current BitC prototype compiler is a whole-program static compiler. > > At the moment, it isn't terribly useful, mainly because I was struggling > > to find any clean way to make it "feel" like a traditional separate > > compilation tool. > > > > Since we need to move forward, here is the plan. Comments, critiques, > > and problem identifications would be greatly appreciated! > > > > File Extensions: > > > > .bitc Used for bitc interface files (only). > > .bits :-) Used for implementation "source" files. > > .bito Used for "object" files. A "bito" file actually contains > > BitC source code, but all of the unit-at-a-time passes have > > already been applied, notably including lambda hoisting > > and closure conversion. > > Currently, the closure conversion and function hoisting is done after > poly-instantiating polymorphic definitions. This is because knowing the > concrete types of definitions helps us determine which non-locals must > be refized (add a ref-indirection for preserving mutation effects). > It is possible to do this refization conservatively before > poly-instantiation if necessary.
Thank you for this correction. It isn't necessary for closure conversion to happen here. The lambda hoisting that I was referring to was instLamHoist, which *is* done on a per-UOC basis. > The current unit-at-a-time passes (that is, not including closure > conversion) do not make major modifications to the AST. So, I think that > the .bito file can have the same content as the input .bitc/.bits files. Yes. In fact, the emitter for the "bito" output language is implemented by the pretty printer. Fastest target language implementation I have ever done in my career. :-) shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
