On Sun, Jan 12, 2014 at 4:40 PM, Ben Kloosterman <[email protected]> wrote:
> >> 1. The CLR safety verifier is going to seriously get in the way of >> perform-ant code. >> >> 3. Which parts of the safety verifier ? If its the one i'm thinking its >> normally disabled. >> > We're going to rely on region analysis for certain kinds of liveness safety. That kind of safety argument simply can't be expressed to the CLR verifier at all. > Regarding the main concern , I'm not convinced of that unless you are > pushing things. Forgive me if im wrong but i thought you would want to get > to self host ASAP... > There are three objectives, roughly in sequence: 1. Get something working so that we can begin a self-hosted implementation. This can be done in either environment. I can do it faster in a Linux-hosted environment than I can in CLR. 2. Re-do that in BitC itself. 3. Begin working on a BitC-specific optimization and code generation framework, because we appear to need one. The first can be done in either environment. While I agree that doing a *good* GC is hard, doing a stop-the-world GC really isn't. There are several examples of success on that using LLVM that have been done in a day or two. The second can be done either environment, though if we host on CLR we are permanently hampered by the limits of CLR. The third is the interesting one. Ultimately, I don't think that *either* CLR or LLVM are going to do it for us. CLR because of the safety requirements and LLVM because it doesn't track object references. Of the two, however, I think the prospects for an incremental migration path from LLVM to something new are much better than the same prospects for CLR. > The fact the original code is C++ is an issue... > I don't see that as an issue. There is some code there that I will steal, but this is a ground-up restart in any case. Managed C++ is a fourth-class unacknowledged bastard stepchild in the CLR world. No thanks. :-) It also means more of the runtime will be self hosted faster as i does not > need to be written twice ( which means it will be lost ) eg the file loaded > would be bitc not C++ legacy. > That is a possibility. It depends on how we approach step 1. If step 1 is "compile to object" then what you say is likely to be true (though it isn't clear to what degree). If step 1 takes the form of a "load and go" implementation, always compiling from source on every execution, it seems like very little should be wasted. That eliminates the need to define, dump, and reload any intermediate object file format. > The #1 issue I have with C++ is your pretty much locked in to 1 platform , > its expensive to do the whole multi platform support,which mean other > platforms get left behind . You can waste an awe-full lot of time here > getting Darwin , Windows , Linux and Android working ( especially around > autoconf) and if you leave them it gets harder and harder. With CLR it > just works and its easy to set some test bots up from the start for all > platforms. > It's interesting. What you say is very much a matter of perspective. I've been working around autoconf for years, so I don't really see it as much of an impediment here. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
