[bitc-dev] Change to compiler behavior

[Jonathan S. Shapiro]

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