On Sat, Jul 13, 2013 at 6:28 PM, Bennie Kloosteman <[email protected]>wrote:
> I had a very close look at mono last year and was very disapointed... > Bennie: First, I want to say thanks for this feedback. It's very useful. A couple of quick reactions and questions. 1. Bounds check elimination in CLR is a *lot* harder than it should be. The definition of CLR leads to some aliasing problems for bounds checks in the presence of multiple threads that are *very* hard to eliminate. Not claiming that mono does this well - in fact, I don't have any idea how well or badly mono does. What I *can* say is that I had an extended discussion about this with some people very knowledgeable about CLR, and it's very hard to get this right. 2. How much of what you say is true in the mono-llvm path? There has been a lot of work in that direction, and I'm not clear what the yield has been. Do you know? If you are able to expand on the issues in the mono-llvm path, that would be very helpful to me. 3. One of my concerns is debugging. Whatever mono's flaws may be, the debugging and introspection support in CLR (therefore in mono) is pretty rich. My intuition is that this will be valuable in debugging my compiler, even if CLR is not the ultimate target. I have no intuitions at all about how much this is true in LLVM. 4. Why a direct fork of Rust? I'm completely in the dark about how Rust is relevant here. Can you suggest things I should go read up on to get my head around it? > If you just want to get something out there mono will do the job and > fairly quick ( as the run time is reasonably easy to targtet ) but it wont > go anywhere.. > Fair enough, and point well taken. The question for now is: what's the best place to do language bring-up rather than a high-performance implementation. Given that statement of the problem, does your assessment change? Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
