[Grace-core] Minigrace on LLVM

[Michael Homer]

On Tue, May 31, 2011 at 12:15 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
> A high level question.  Why did you choose LLVM as the target?  I have no objection to it in principle, but am concerned that there is no garbage collector.  Is there one easily available that we can integrate into our system?  Obviously garbage collection is not important at this stage, but it will be when people start using it.  Thus, I am concerned that if we (you) spend the effort on targeting a relatively low-level VM then it might not be a good long-term investment.  I don't have any emotional commitment to the JVM (especially because of generics and arrays), but it does include a garbage collector.  I'm certainly open to other options as well, but eventually we do need garbage collection.

I chose LLVM as a target that wouldn't enforce an object model I would
have to work around, and that would provide standard compiler
optimisations without my having to implement them myself, so I could
focus on the high-level language-dependent functions. It also produces
native code in a cross-platform way, and compiling the language into
actually efficient native code is a potential research topic itself.

As far as garbage collection goes, while LLVM doesn't include a
collector itself it does provide intrinsic hooks (@llvm.gc*) for
providing points of attachment for collectors (see
<http://llvm.org/docs/GarbageCollection.html>). Building a code
generation plugin attaching to those hooks to implement a collector
can be fairly simple, up to as complex as required. The collector will
need to be specialised for Grace objects. Potentially multiple garbage
collection algorithms could be developed and assessed against each
other - they would just plug in and out at code generation time.

It should be possible to integrate a conservative collector like Boehm
without those hooks as well. There is also VMKit
(<http://vmkit.llvm.org/>), an LLVM-based virtual machine
infrastructure that was made for a JVM, and which could be of
assistance.

>
> Our own implementation is still very high level (read, very inefficient) to help work out the language design issues.  I'm very happy that you are getting so far with this, but I don't want you to go to lots of extra effort if you'll have to switch later (unless you think it will be an easy port).

I hope that it shouldn't be overly much work to port to another target
(I have an idea of producing a version that outputs JavaScript). Most
of the code is concerned with parsing and postprocessing, and the code
generation parts are often fairly simple, combining the results of a
few other generative steps with a couple of bitcode instructions. At
the moment the code generation is very intermingled, but I have to
separate it out at some point anyway - once I have proper classes and
types it will all need revision.
-Michael