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.
So a compile line will look like:
bitcc -c mumble.bits ... -o mumble.o
The actual code generation happens at the "link" stage:
bitcc -o a.out x.bito y.bito z.bito ...
The compiler will internally generate some god-awful ugly .c file, and
will proceed to hand that to GCC for compilation.
Eventually, we'll make provision for archive libraries of .bito files.
Actually we need those for other reasons in any case.
The main reason that I need to nail this down is that we need to start
implementing parts of the BitC standard library. Some parts of that
library want to include polymorphic functions.
I do recognize that there are various tricks which can be played here to
make all of this more efficient. Many of those tricks can be done
without altering the command line framework above, but for the moment
I'm looking to get it working at all rather than worrying about the
"link" speed.
Reactions?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
