On Wed, Mar 10, 2010 at 7:16 PM, Jonathan S. Shapiro <[email protected]> wrote: > First, note that there are paths from CLI to native code for a number of > platforms. The Mono 2.6 infrastructure includes the ability to use LLVM as a > code generator. When coupled with their AOT technology, I would not be > surprised if we can get nearly complete target code generation right now. > Certainly it shouldn't be a big technical leap to get there given the work > that they have already done. Finally, mono seems to be moving to a > relocating collector.
> Concerning CLI, you can say a lot of things about it, but it is an > environment that has strong tools and strong debugging support, and one that > supports a fully incremental edit-compile-debug loop. I am sure you're aware of this concern, but using CLI as the main development backend for BitC might make early multi-OS support a bit difficult. If you and the main BitC developers work with Mono, as opposed to .NET, it will surely alleviate this somewhat. Regarding Mono's LLVM backend, I'd like to raise some concerns with JIT in LLVM, which Mono uses, IIRC. It has been a bit buggy in the past 12 months, and a bit of a moving target. The fundamentals are sound, I would say, but the API has been changing and some things like memory allocation in the JIT code were a bit funky. The Google people working on Unladen Swallow (Python LLVM-backend) have had to battle with it as well. In principle, the LLVM 2.6 release should have addressed many of these concerns, however. Not to frighten you away from LLVM, it is great stuff and very actively developed. But there are some issues with it, and their SVN has been a bit chaotic. Some of its trumpeted advantages may not be as significant as some would like to say. I've never been able to reproduce LLVM's backend supposed speed advantage over GCC, and some of the optimizers have some nasty asymptotic behaviors (quadratic or cubic in code size, visible on very large functions). My point is simply that LLVM is still fairly young, but if you stick to its core and a stable release (e.g. what Apple has been using in OSX) you'll be just fine. Please note that many or most of these concerns might have been addressed in the 5 months I haven't needed to follow LLVM development. Since we're talking about backends, I would like to mention the approach chosen for the Go programming language (released by Google some months ago, coming from people like Ken Thompson and Rob "Commander" Pike). See http://golang.org. Go is a lowish-level language, garbage collected, that aims for C-like performance. They also have strong support for concurrency. A few of its design goals overlap BitC's (but not all, to be sure). They wanted very fast compilation (100,000 lines of code in seconds) and wrote their own compilers and code generators for x86, x86_64 and ARM. They also have a GCC backend (slower to compile, but produces better code). Their custom backend is written in an old-fashioned terse C style. Not for the faint-hearted. Their GCC backend uses a C++ layer, written by Ian Lance Taylor (he wrote the very fast Gold linker), that is actually very clean and shows quite well how to sanely write a frontend for GCC. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
