If you're willing to defer manual memory management for awhile, GHC core [1] is a good target since it supports unboxed types [2], and you can output the core [3] and inspect/debug it. With a suitable monadic library [4], you can even add manual resource management, although I suspect compiling large programs with a lot of resources will be quite difficult.
I personally think C as a target is the only way to go if you're not happy with LLVM. I recently came across the most trivial and yet reasonably performant real-time GC in the CHICKEN variant [4] of the STOPLESS collector, so building your own GC won't take long. With C as your target, you can unbox to your heart's content. And since you can build a scheme-to-c compiler in 90 minutes [5], BitC shouldn't be too hard. ;-) Really all you need is closure conversion and a type class dictionary passing transformation, all of which you can build as source-to-source BitC, with a final BitC-core-to-C pass. Deferring mutually recursive tail call support is reasonable IMO, but even that can be eventually handled by merging functions and using goto. Sandro [1] http://typesandkinds.wordpress.com/2012/12/03/a-formalization-of-ghcs-core-language/ [2] http://www.haskell.org/haskellwiki/Performance/GHC#Unboxed_types [3] http://www.haskell.org/haskellwiki/Performance/GHC#Looking_at_the_Core [4] http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf <http://www.cs.technion.ac.il/%7Eerez/Papers/real-time-pldi.pdf> [5] http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf <http://www.iro.umontreal.ca/%7Eboucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf> On 13/07/2013 2:57 PM, Jonathan S. Shapiro wrote: > I'm toying with some language ideas. BitC-the-first failed for various > reasons, and I'm trying to work out how to get what I learned into a > viable production language. At the moment I have a very mundane > question, and I'd like input. > > One of the implementation mistakes in BitC was the decision to use > C++/Boehm-GC as the implementation language. At the time, it seemed > the best of bad options. Mono wasn't far enough along at the time to > be stable, and LLVM's GC support wasn't soup yet, The only viable > alternative seemed to be Java. Java would have worked as an > implementation language, but the JVM lacks adequate support for > unboxed types, and if I was going to eat the learning curve for a > whole new runtime, I really wanted to use it as a /target/ runtime as > well. > > Today I think that situation has changed. > > CLR support on linux is now good enough, and with the exception of > unboxed arrays it has everything we need to have to serve as a target > for a BitC-like language. There are safe (that is: recognizably safe > in the eyes of CLR) structural encodings of all of the BitC data > types, and the array issue has workarounds. While I don't want CLR as > a primary final target, it's a fine target to have and provides a lot > of useful stuff for developing a new language. > > The other option is to re-consider LLVM. There are now several > examples of GC'd languages that are successfully targeting LLVM, and > the LLVM infrastructure is pretty robust at this point. There are > bindings for LLVM from both C# and Java. For purposes of building the > initial compiler, there are LLVM bindings available from both Java and C#. > > I gather that the DaVinci project was adding support for unboxed types > to the JVM. I don't understand the state of that, and the page is > presently inaccessible. But unless DaVinci provides real support for > value types, I don't think JVM is an option. > > The /disadvantage/ to CLR is that the mono and monodevelop projects > have been handed to Xamarin, who have made it clear that working on > linux problems isn't a priority. JVM, on the other hand, works pretty > much everywhere. If we think that LLVM is a better final target, it > might be better to implement in Java targeting LLVM from the get-go. > I'm not sure. > > What other language virtual machines am I failing to consider? What is > the current state of DaVinci? Does anybody have recent experience with > GC in LLVM? > > > Jonathan > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
