[llvm-dev] A "Java Backend"

Lorenzo Laneve via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 21 01:31:14 PDT 2016


I thought about something like that but I think it's not a good idea.
Like writing an AST visitor on Clang for example would be cool but it isn't open to other frontends, and I think that this is a job for LLVM.
What about java-* attributes that can be put on certain IR operations to indicate structures that are needed to know about the Java Bytecode structure, or operations that should be translated in a specific way for Java?
These attributes can be added to the IR modules optionally like debug info

> On Jul 19, 2016, at 5:28 PM, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote:
> 
>> On 19 Jul 2016, at 15:52, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>> 
>> But you're right that it will still be difficult to naively
>> inter-operate between Java and C++ objects.  Which is why it will be
>> an interesting research project. :)
> 
> If that’s your goal, then you might have better luck doing source-to-source than going via LLVM IR.  In the past, I’ve managed to do most of Objective-C (not goto, pretty much everything else) -> JavaScript and Dart using clang AST visitors, with Objective-C classes being represented as native objects, with a bit of glue code to paper over the differences in the object models.  With C++, you would most likely want to implement subclassing as composition and make each C++ class a Java interface so that you could do all of the kinds of casts required for multiple inheritance.
> 
> There have been a few attempts at C to Java compilation, though I’m not sure of the current status of any of them.  gcj implements Java classes using the same ABI as C++ classes, effectively treating Java as a subset of C++ (plus garbage collection).  It might be interesting to start with the same subset of C++ that Microsoft has used for one of their various C++-on-the-CLR implementations and work from there.  I think Alp Toker had some parsing for MS managed C++ extensions and CLR code generation working a few years back, but I’m not sure what happened to his code.
> 
> David
> 


More information about the llvm-dev mailing list