Mips2Java solves the same problem. The latest version of Mips2Java is called NestedVM and is part of the larger Vexi project. Much work has been done on NestedVM and it is quite impressive. http://wiki.vexi.org/ Still, it could use a lot of improvement. It's biggest immediate problems are: 1) It doesn't integrate well into a standard (Ant-based) Java build 2) There is no documented support for JNI It would obviously be quicker to fix these problems with NestedVM than to get LLVM to the same point (in terms of JVM support) that NestedVM is now. Once that point is reached, the remainder of the effort would be almost exclusively optimization. LLVM would seem to provide a better base for optimizing the runtime. If LLVM binaries can soon be made to run more quickly than NestedVM binaries, it would be a positive affirmation of the principles of LLVM. Perhaps the MIPS instruction set is really better suited for running C/Fortran binaries on a JVM. Given the design goals of LLVM, it doesn't seem likely. - Curt
On Tue, 1 Mar 2005, Curt Cox wrote:> Mips2Java solves the same problem. The latest version of Mips2Java is called > NestedVM and is part of the larger Vexi project. Much work has been done on > NestedVM and it is quite impressive. > http://wiki.vexi.org/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? -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
The best overview for NestedVM appears to have disappeared off of the web, so I've attached it.>From the attached paper:The MIPS R2000 ISA bears many similarities to the Java Virtual Machine. Most of the instructions in the original MIPS ISA operate only on 32-bit aligned memory locations. This allows NestedVM to represent memory as a Java int[][] array indexed by page (the top n bits of the address) and offset (the remaining bits) without introducing additional overhead. MIPS's nonaligned memory load instructions are only rarely emitted by most compilers since they carry a performance penalty on physical MIPS implementations. Our choice of a paged representation for memory carries only a small performance disadvantage: <Figure omitted> Additionally, this representation lets us to take advantage of the fact that on most JVM's, checking for a NullPointerException carries no performance penalty unless the exception is thrown (the host CPU's MMU is generally used to detect this condition). This allows us to lazily expand the MIPS memory space as it is used. Additionally, we maintain two page arrays, one which is used for read operations and another for writes. Most of the time these page arrays will have identical entries; however, we can simulate a portion of the MIPS MMU functionality by setting the appropriate entry in the write page table to null, thereby write protecting the page while still allowing reads. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, March 01, 2005 11:14 AM To: LLVM Developers Mailing List Subject: RE: [LLVMdev] Using LLVM to target the JVM On Tue, 1 Mar 2005, Curt Cox wrote:> Mips2Java solves the same problem. The latest version of Mips2Java is > called NestedVM and is part of the larger Vexi project. Much work has > been done on NestedVM and it is quite impressive. > http://wiki.vexi.org/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? -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: nestedvm.ivme04.pdf Type: application/pdf Size: 148677 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050301/1967b9f4/attachment.pdf>
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
"Curt Cox" <ccox at tripos.com> writes:> Mips2Java solves the same problem. The latest version of Mips2Java is called > NestedVM and is part of the larger Vexi project.Actually Brian and I wrote it as part of the Ibex project. http://www.megacz.com/research/papers/nestedvm.ivme04.pdf> Wow, they are very serious about this.Yep, quite serious. ;) - a