From: Rick DeNatale <rick.denatale@...>
Date: 2009-06-04T23:34:26+09:00
Subject: [ruby-core:23704] Re: Standard Ruby bytecode

On Thu, Jun 4, 2009 at 7:36 AM, Eero Saynatkari <ruby-ml@kittensoft.org> wrote:
> Excerpts from Ioannis Nousias's message of Thu Jun 04 12:11:06 +0300 2009:
>> my question to the ruby developer community is: has anyone considered
>> using LLVM's [1] bytecode for this purpose. I don't know how applicable
>> it is, but I would expect certain advantages using a well establish
>> format, instead of yet-another-custom-bytecode, with the potential of
>> taping into LLVM's resources.
>
> In short, it is not possible to "use LLVM's bytecode" for
> this, because it is not representative of a Ruby program.
> Basically, that question is the same as "is it possible to
> use ASM to represent a compiled Ruby file?"
>
> (By the by, LLVM uses the term "bitcode" -- not a nag, it
> will just be easier to search for those terms)
>
> It is certainly possible to actually use LLVM and thereby
> possibly its bitcode which is what Rubinius is doing (as
> is MacRuby?) If such bitcode were dumped, though, it would
> still be highly dependent on the target VM,

I have to agree with this.  My brief analysis of LLVM and it's
'instruction set' impresses me that it's much more targeted towards
statically typed languages.  The motivation of LLVM seems to be to
provide a common internal representation for GCC like compilers. In
many ways it seems to be a reinvention of the uncol idea from the late
1950s:
http://en.wikipedia.org/wiki/UNCOL

The call and invoke instructions appear as if they make no concessions
for rubyish method dispatch, or even the more static virtual function
linkage in the JVM.

The JVM guys are already working on supporting more dynamic invocation
in order to better support languages like Ruby, see the slides from
the presentation given two days ago at JavaOne by John Rose and Brian
Goetz:
http://blogs.sun.com/jrose/entry/tuesday_at_javaone

So LLVM starts out behind other VM architectures like the JVM which
are moving to better support dynamic languages.

Another issue with LLVM seems to be the approach to GC integration.
While LLVM does provide for interfacing to a GC with things like
read-barrier and write-barrier hooks, it requires the compiler to
insert these into the bitcode.  This is in contrast to most of the GC
VMs of which I'm aware which handle gc bookkeeeping inside the
implementation of bytecodes.  And the actual GC implementation is done
by language/implentation specific plugins. There seem to be questions
about how efficient a GC implemented within the LLVM framework can be
in contrast to GCs built in to a VM.


-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale