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 >
On 21 Jul 2016, at 09:31, Lorenzo Laneve <lore97drk at icloud.com> wrote:> > 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 infoI’m not sure what problem you’re trying to solve. Providing these attributes from the front end and ensuring that they’re correctly preserved by optimisers would likely be more effort than writing a Java bytecode back end (and a lot more for any language that has a simple mapping to the Java object model). By the time code is in LLVM IR, it’s already got a lot of assumptions about things like calling conventions and data layout embedded in it. You’d need to treat the Java back end as another target in your front end (and a particularly weird one, at that). If I had a front end that I wanted to use to target the JVM then I would not go via LLVM IR to get there. The same probably holds for the CLR, though it’s a little bit less clear cut. David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3719 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/289149d7/attachment.bin>
Passing through LLVM IR would enable LLVM to apply its optimizers and, as I said, I know that creating a custom standalone backend could be easier, but enabling LLVM to translate to Bytecode would enable all of its frontends to do it. I know that it might be quite hard to treat Java or .NET as LLVM targets, but could this be a challenge? Let LLVM IR be compiled to Bytecode and CLI, which are higher level than our IR.> On Jul 21, 2016, at 11:36 AM, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote: > >> On 21 Jul 2016, at 09:31, Lorenzo Laneve <lore97drk at icloud.com> wrote: >> >> 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 > > I’m not sure what problem you’re trying to solve. Providing these attributes from the front end and ensuring that they’re correctly preserved by optimisers would likely be more effort than writing a Java bytecode back end (and a lot more for any language that has a simple mapping to the Java object model). By the time code is in LLVM IR, it’s already got a lot of assumptions about things like calling conventions and data layout embedded in it. You’d need to treat the Java back end as another target in your front end (and a particularly weird one, at that). > > If I had a front end that I wanted to use to target the JVM then I would not go via LLVM IR to get there. The same probably holds for the CLR, though it’s a little bit less clear cut. > > David >