On 01.02.2016 17:32, Alexander Bertram wrote:
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.
that is quite bad... the JRE is big
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)
since you worked with gcc as well I am wondering if gcc actually allows
the joint compilation of multiple languages. assume for example there
would be a part for java and one for groovy and you have a java class A
extending a groovy class B extending a java class C, and C has a field
of type A and another one of type B.... bad structure, I know, just for
the sake of the example... then, unless you do a true joint compilation
in which you resolve the classes in the same compilation you cannot
compile this, since you cannot even split the compilation steps anymore.
Does gcc provide something here? With just IR this is not done, unless
class resolving would be done on the IR code and given that the IR is
almost assembler I fail to believe that, as too much information is
already lost in that part.
So assuming this won't work I am playing around with the following idea...
* each language will generate private AST able to interface with a AST
based on javax.lang.model
* the compiler will implement a class resolving structure, which each
language must implement
* optionally we generate asm tree structures as kind of IR
* generate bytecode directly or from IR (language plugin decides what it
wants to do)
* output to files or in memory...
naturally this would be still a very Java oriented compiler, but I
imagine with such a structure you could do a lot of things... and easily
extend it for use in Java based IDEs for example.
[...]
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.
yes, that would be a good idea.
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.
