Hi,
For my PhD research, I'm working on an aspect language for C, called Aspicere. References on Aspect-Oriented Programming (AOP) can be found on http://aosd.net, but basically aspects are modules which encapsulate all related functionality (called advice) of a particular concern (logging, persistence, ...) as well as conditions (pointcut expressions) expressed on a regular program to indicate where advice should be triggered during execution of that base program. As such, multiple concerns are separated more cleanly to facilitate better code reuse, program comprehensibility, ... . A weaver mixes both aspects and base program at compile/load/run-time. Most AOP tools are developed for Java (AspectJ, ...), but in fact AOP is not tied to one language, nor to OO-languages.
Currently, Aspicere's weaver transforms a C program by manipulating an XML-representation of its Abstract Syntax Tree (AST) and then hands it down to GCC (so it's a source-to-source weaver). A new prototype will be available soon on http://allserv.ugent.be/~kdschutt/aspicere/, featuring a Prolog-based pointcut language.
To extend our work to C++ or even Java, we'd face two main problems: offering a suitable pointcut language for each particular language and an efficient way to effectively weave aspects. The former problem can be handled by designing different layers of Prolog predicates, such that the frontend predicates for the different languages eventually rely on the same basic predicates. The latter issue would force us to invent new XML-representations for all the desired base languages or, much more challenging, design one uniform formalism for all of them. These solutions are either tiresome or too monolithic. And what about the efficiency of either the woven code and the weaver itself?
GCC is the primary compiler on Unix/Linux systems and has also been ported to numerous computer architectures. The new GCC 4.0.0 features two incarnations of a new intermediate representation (IR): GENERIC and GIMPLE trees. If we let our weaver operate on these instead of on custom XML representations, our second problem can be solved. Because all GCC-supported languages (C, C++, Objective-C, Fortran, Java, and Ada) fall back on the same IR, advice code written in C could theoretically be applied to e.g. a Fortran application. So, apart from more efficient weaving capabilities on a plethora of platforms, building an aspect weaver into GCC itself would also facilitate language-independent weaving.
A very schematic outline of what I'm intending to do:
1) C's frontend generates IR of base program and aspects (advice code is pure C)
2) Prolog engine is given a Prolog representation of pointcut expressions as well as access to IRs
3) Prolog engine selects appropriate IR-nodes where corresponding advice should be woven
4) IR is modified (actual weaving of advice in base program)
5) normal GCC operations continue
So, I'm about to investigate these ideas. As I'm fairly new to GCC's internals and source code structure, I'd like to pose the following questions:
1) Are these plans feasible? Is somebody else already doing similar things?
2) Where can I find the most documentation about the SSA trees, navigating through them, modifying them, ...?
3) Where should I start to look in the source code?
Any comments or suggestions are welcome. If some things seem rather unclear, don't hesitate to ask for more explanation.
Kind regards,
Bram Adams SEL, INTEC, Ghent University (Belgium)
