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. 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. Once the unit-at-a-time passes have run, the program is guaranteed to have no compile time errors. Swaroop. _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
