On Mon, Jan 13, 2014 at 6:12 AM, Jonathan S. Shapiro <[email protected]>wrote:
> Ben: > > CLR is a mixed bag - it's not well received in the linux world, for > example. But that's mostly beside the point. There are three problems with > CLR from my perspective: > - Linux is a many groups .. but the one you are talking about is against any JIT / GC runtime ( Java included) and mainly in favor of open source code distributions which are binary compiled by them. Also Linux ( excluding the corrupt android that will be being replaced soon by a real linux :-) ) is a small market segment that is absolutely full with new languages ( Its certainly behind Android , ios , Windows and OSX in total count though strong in the server market) . If it was a business case it would be the last plaform id go for. > 1. While I can work in C#, I'm about twice as fast in C/C++, and I > want to get something built. > 2. While the CLR assembly format is rich in the way that you say, it > isn't rich enough for BitC and so needs to be reinvented in any case. I'd > rather do that "clean" rather than trying to shoehorn things into CLR. > 3. The CLR safety verifier is going to seriously get in the way of > perform-ant code. > > Of these, [1] is the important one. > 2. Adding byte codes requires no change . 3. Which parts of the safety verifier ? If its the one i'm thinking its normally disabled. 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 is no need to do any fancy features bar some interfaces to make it easier to change. External reading and writing of a lib can be done with IKVM until you self host - why write custom code that will go when you self host . The fact the original code is C++ is an issue but some of the inheritance based stuff will need to go when you self host. Also you can write managed C++ , normally i would not recommend it (as its a bit esoteric with gcref ) but as an interim which will get thrown out when you self host it may work , as long as you keep it simple and don't dive to deep . 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 . Its worth noting that LLVM can generate CIL from IR but because it looses so much information it performs poorly. I don't think this is an issue going the other way . Lastly you would have LLVM static compiler "as well" before you finish self hosting via CIL to IR conversion . Though you would not have a proper GC that will take time but this seems ideal LLVM static for no heap coding and decent performing JIT to get other things up 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. That said you still need it for the non CLR ( ie CLR to LLVM ) static compile but its a smaller area and if mostly CLR Bitc code should hopefully be more multiplatform ( Note LLVM IR by default is platform specific there are less well tested multi platform IR instructions which i was looking up but its poorly documented) . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
