Re: [Libjit-developers] libjit vs LLVM

[Chris Lattner]

On Fri, 28 May 2004, Gopal V wrote:

> > > > > P.S. LLVM is very cool - I have nothing
> > against it per se.  I've merely
> > > > > set my sights a little lower in the interest
> > of VM authors.
>
> LLVM would be like build an intermediate byte code
> and process that, while libjit is to build the in
> memory tree ..

I'm sorry that I was not clear.  LLVM *can* build a bytecode file, or it
*can* build an in-memory tree and emit code from that.  There is no reason
that you have to go to or from bytecode with LLVM, it just makes it a lot
easier to visualize the code that you are executing (which is obviously
not needed in the normal case when you are just executing code).

> I don't think libjit'll ever have an in memory (or
> otherwise) bytecode format .. because that is not
> what it is designed for ...

I suspect that there are debugging dumps that you can get to see the code
being compiled.  This is no less than an ad-hoc form of the LLVM assembly
format.

> Loading stuff off a disk and loading the same format
> off memory both have a few performance hits in memory
> consumption , which libjit does not have as it needs
> only one bytecode loader and not two like LLVM would
> need , for example to write a JVM with (AFAIK).

I understand what you're saying, but fortunately that's not true.  You can
do exactly the same stuff you can with libjit, including interfaces like:

F = new function()
F->appendAddInstruction()
F->addReturnInstruction()
void (*FP)() = getPointerToFunction(F);   // <-- JIT compiles the function

The method names are different, but that's the idea.  There is no reason
to go to bytecode or text form at all.

> > things like this.  As such, LLVM isn't "adapted to
> > function as a JIT", it
> > *INCLUDES* a JIT as one of its primary components.
>
> Rather than compare LLVM to libjit, I'd like to compare LLVM to .NET
> itself ... which lets you compile different language into the same
> bytecode and execute it. Or the dynamic method creation
> (Reflection.Emit) looks similar to what LLVM does before JIT'ing ...

Funny you should mention it, but i'm currently working on a .NET front-end
for LLVM.  If you're interested in the differences between high-level
virtual machines and LLVM, I recommend taking a look at this doc:
http://llvm.org/pubs/2004-01-30-CGO-LLVM.html

In particular, .NET really only supports languages that use it's object
model, where LLVM can support *any* source-language (just like a
microprocessor can).  In addition, LLVM supports a lot of aggressive
optimizations.  For example, if you were using LLVM as the JIT component
of a raytracer to accelerate shaders, you would want to take advantage of
the loop unroller and other optimizations built into LLVM.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/