llvm dev - Mar 2005 - [LLVMdev] Using LLVM to target the JVM

On Mar 1, 2005, at 12:13, Chris Lattner wrote:
> Interesting, do you know of any documentation that describes how this 
> works?  Does it just map the memory image for the mips program onto a 
> giant array of bytes?
int32 values, actually. The best documentation I have found is the 
description of mips2java. It seems to be down, so I've included a link 
via google's cache

http://www.xwt.org/mips2java/
http://64.233.167.104/search?q=cache:QblfYsocEuQJ:www.xwt.org/mips2java/

Here is the relevant information:
> Architecture Representation
>
> Conveniently, we can represent main memory as a Java int[][], which 
> allows efficient accesses so long as they are aligned, 
> 32-bit-word-at-a-time accesses. The first index is the top 16 bits of 
> the address; the second index is the lower 16 bits. This allows us to 
> allocate Java memory to the MIPS emulator in 64kb slabs.
(there are more details on that page)

Evan Jones

On Tue, 1 Mar 2005, Evan Jones wrote:
> On Mar 1, 2005, at 12:13, Chris Lattner wrote:
>> Interesting, do you know of any documentation that describes how this 
>> works?  Does it just map the memory image for the mips program onto a
giant
>> array of bytes?
>
> int32 values, actually. The best documentation I have found is the 
> description of mips2java. It seems to be down, so I've included a link
via
> google's cache
>
> http://www.xwt.org/mips2java/
> http://64.233.167.104/search?q=cache:QblfYsocEuQJ:www.xwt.org/mips2java/
Wow, they are very serious about this.

Okay, so I don't know exactly what your (Curt's) goals are, but
here's my
impression.  If you want to do a fully general LLVM->Java translator (not 
an interpreter) it should basically start as a system similar to 
MIPS->Java, including the whole memory mapping thing (but probably at a 
byte level, not int32 level).

The MIPS->Java implementation is really a mips interpreter written in 
Java.  If you cared about performance (again, I don't know what your 
motivation is), it would be straight-forward to statically compile LLVM 
code to Java bytecode (or, equivalently, java "assembly").  This would
make the resultant code MUCH faster, and would allow you to do other nifty 
optimizations.  For example, you could do simple analysis and promote LLVM 
arrays to Java arrays, bypassing the whole memory mapping thing in some 
important common cases.  We also have some analyses that can tell you if 
memory is accessed in a type-safe way.  You might be able to use this to 
promote higher-level objects and structures to be real Java objects 
instead of dealing with the memory map.

Again, I'm not sure exactly what your motivations are, but this sort of 
thing is certainly doable, and I don't think anyone is working on it.  :)

-Chris

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

The reasons I'm interested in are compiling legacy Fortran/C code to Java
bytecode are:
1) to run the same binaries on all platforms with a supported JVM
2) to run in environments with security restrictions (AKA sandboxes)   

I care about performance.  A major reason that I'm attracted to LLVM is that
it would seem to have a better upper limit for attainable performance.  My
primary interests in a LLVM interpreter comes from its potential educational
value to me.  If I could write a working interpreter, then hopefully, that
would mean that I understood the LLVM bytecodes.  Perhaps an interpreter
would also be useful for debugging or developing a continuously profiling
runtime for LLVM like HotSpot.

- Curt