On Wed, Mar 10, 2010 at 2:33 PM, Philipp Klaus Krause <[email protected]> wrote: >> Indeed, compiling direct to assembler is far better than compiling to C. > > Why?
Three main reasons: 1. The BitC type system expresses things that cannot be expressed in C. Once the program has been "spit out" as C code, that information is lost. Some of the things BitC can express allow us to consider optimizations whose correctness cannot be seen by a C compiler. 2. C cannot express programs that are compatible with precise garbage collection without a significant loss of performance and clarity.. See, in particular, the work by Fergus Henderson (Accurate Collection in an Uncooperative Environment) Jon Rafkind (Precise Garbage Collection for C) and Adam Wick's work on MagPie. There is a bunch of other work pursuing similar ideas. 3. It is actually quite difficult to express first-class procedures with closures in C. If you look at the current BitC runtime, you'll see that we had to appeal to an assembly stub trick for this. On some platforms (notably Apple), the C calling convention doesn't really give you a good way to express call-with-closure without going to assembly language. > And what do you mean by "compiling to assembler"? I suppose that's > compiling to x86... Philipp: It's very okay to be new here, but you probably haven't been around long enough to know that I try to write precisely. I certainly do *not* mean x86. In fact, the only reason I can think of to target x86 at all is legacy compatibility. I *do* mean machine-dependent assembly code that is fully cognizant of the native capabilities of the machine. Today, for native code, I think I would look at LLVM again. It has come a long way since our last look, and others have taken the trail that we chose not to follow back then. But eventually, I want a code generator built on safe and analyzable infrastructure. > C is today's (only) portable assembler. Yes. And unfortunately, it's quite bad at expressing some of the things that we really need to express (see the list above). Might very well amount to a 15% performance penalty, if not more. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
