[Soot-list] Adding new output format to soot?

[Prof. Laurie HENDREN]

Hi Ulrik,

I think you should look at JC, at:

http://jcvm.sourceforge.net/

I am sure you can learn from this system,  and Archie Cobbs (the author)
could tell you how Soot worked on this project.

Cheers, Laurie


+-----------------------------------------------------------------
| Laurie Hendren --- laurie.hendren at mcgill.ca
| Associate Dean (Academic), Faculty of Science,
| Dawson Hall, McGill University, 853 Sherbrooke St W,
| Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
+----------------------------------------------------------------
| For contact and home page info as Professor, Computer Science:
| http://www.sable.mcgill.ca/~hendren   ---  hendren at cs.mcgill.ca
| Research: http://www.sable.mcgill.ca  http://aspectbench.org
+----------------------------------------------------------------

On Mon, 14 Nov 2005, Ulrik Pagh Schultz wrote:

>    hi,
>
> I'm starting a project with a student on a Java to C compiler for
> embedded systems, and we are considering using soot as part of this
> project.  We need optimizations like dead-code elimination and
> devirtualization, and would also like to use 3-address code (jimple
> seems fine) rather than the standard stack-based representation.
>
> We've played a bit with soot from the command line, but we're still
> not convinced if it's the right tool for the job.  So if someone has
> an opinion on whether the following seems feasible and maybe even has
> a few pointers on how to get started with adding a new output format
> to soot, we would very much appreciate it.
>
> We imagine starting with jimple, and want to make use of annotations
> indicating e.g. unused methods to avoid including them in the output
> program.  We would also want type information to eliminate virtual
> dispatches (we would rather avoid inlining and method duplication in
> general, since we are interested in saving space, and hence want to
> avoid code duplication) etc.  To generate C code, we basically need
> to traverse the annotated jimple AST collecting information and
> generating code.  (This project is for an MS, so the more time we can
> save by not having to create a whole compiler infrastructure, the
> better.)
>
> An alternative to integrating directly with soot would be to use the
> XML output format and then build our own framework independently of
> soot, but this would probably be a larger effort and more importantly
> it's hard to tell whether all annotations can be included in the XML
> output?
>
> So: any opinions on the amount of work required and any hints as to
> where to start in the framework?
>
>   thanks,
>    Ulrik & Martin
>
> --
> Ulrik Pagh Schultz, associate professor, University of Southern Denmark
> ups at mip.sdu.dk - http://www.mip.sdu.dk/people/Staff/ups.html
>
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>