The build times with Soot were definitely an issue. Soot is still first and foremost an analysis framework so on startup it builds this enormous data structure of all Java classes reachable from the input, which ends up including most of the JRE.
I also found it difficult to build the Jimple IR programmatically. Soot makes extensive use of singletons so it's not as easy as SomeASTNode node = buildFunctionNode(inputAst) writeClassFile(node) For this reason, I ended up generating a Jimple text file which I fed into Soot to compile to bytecode. This was both slow and meant having to mess around with composing text files as output. I've found the ASM Tree library to be quite nice to work by contrast, and it's made it possible to include some nicieties like debugging info, like stack traces that include C source references: java.lang.ArrayIndexOutOfBoundsException: -1 at org.renjin.gcc.array.sum10(array.c:29) at org.renjin.gcc.array.test(array.c:16) (Was pleasantly suprised that it was then possible to step line by line through Fortran code in IntelliJ) What I do miss after switching away from Soot are tools to "optimize" the resulting bytecode, for example, when you have something like: ILOAD 3 ICONST_1 IADD ISTORE 3 Which can be replaced with IINC 3 My informal testing seems to suggest that these kind of optimizations don't have much impact on runtime performance, but it can mean the difference between a 170k classfile and a 28k classfile, which I do care about. I've partially addressed this with a small number of "peephole" optimizations that run on ASM's MethodNode structure: https://github.com/bedatadriven/renjin/blob/841ffcd2498f618fe50d490ecb12e054ea52fb97/tools/gcc-bridge/compiler/src/main/java/org/renjin/gcc/peephole/IntegerIncrement.java Basically the approach described here: http://users.sdsc.edu/~mtikir/publications/papers/technicalreport.pdf This might be extracted to a nice little library that could be shared among compilers. -Alex On Monday, February 1, 2016 at 4:02:20 PM UTC+1, blackdrag wrote: > > > On 01.02.2016 15:21, Alexander Bertram wrote: > > Have you looked at the Soot project? It's very close to this: > > http://sable.github.io/soot/ > > > > It provides a few intermediate languages such as Jimple and BAF. > > this looks interesting, yes... though because of LGPL (see > http://www.apache.org/legal/resolved.html#category-x) I might not be > able to actually use any of that... but still a good information about > the approach > > > The original version of gcc-bridge used Soot as a backend, but the API > > is a bit cumbersome to work with so in the most recent reworking we use > > ASM to generate code directly from Gimple, which is GCC's Intermediate > > Representation and our input language. > > can you explain a bit why it got cumbersome? How have the build times > been with that compiler infrastructure? > > bye Jochen > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To unsubscribe from this group and stop receiving emails from it, send an email to jvm-languages+unsubscr...@googlegroups.com. To post to this group, send email to jvm-languages@googlegroups.com. Visit this group at https://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/d/optout.
