Source Code Analysis and Transformation Environment

[Objective]

[User View]

[Features]

[Software infrastructure]

Source Code Analysis and Transformation Environment

Objective

The objective of SCATE is to provide a generic environment for fine grained C++/C parsing/analysis/transformation and hardware mapping tasks. The name environment is significant here. It means that the whole infra structure is a software platform which can help you to implement your own C++/C based analysis/transformation/mapping tasks. You are free to use it, but there where functionality is (still) lacking, you are invited to contribute to it as well. To allow new functionality to get in, SCATE is Open Source under the GPL License.

The functionality of SCATE that has been developed so far is a system-level design and programming environment for embedded multiprocessors. Here we consider the mapping of C++ based specifications of embedded systems functions onto heterogeneous multiprocessors containing hardware and software components. In practice this relates to a number of source code transformations on process networks.

Transformations should be specified by a system designer. The enforcement of these design decisions in the source code is automated by the SCATE tool. The source code after transformation can - with or without additional manual modifications - be used as input for existing hardware and ⁄ or software compiler(s).

User view

Figure 1: High level user view on the tools.

Features

Provides an open source (ANTLR generated) C++ parser.
Implements a fine grained heterogeneous AST.
Multi file compilation.
Automatic recognition of YAPI type process networks from C++ sources.
Automatic file and directory restructuring. This provides one (consistent) software modeling style for all transformed application models.
Automatic creation of Imakefiles for all transformed application models.
Configurable API definition, steers API recognition and transformations between API's. Moreover, it allows for the implementation of interface refinement. In order to recognize the network structure form sources the following restriction holds; the creation of the network should be implemented using a YAPI like syntax.
There should be no perception difference between transformed source code, and manual (well written) source code; i.e. source code remains highly readable after transformation.
(Optional) Graphical view on process network in dotty format and ⁄ or SequoiaView format.
(Partial) Flattening of hierarchical networks.
Conversion from C++ to C. The emphasis is not on a generic transformation for every language construct, rather we assume the main function of a process or task is rather close to the C language already. This requires an API definition in the C language.
Integration with Qt allows for the development of user interfaces.

Software infrastructure

Figure 2: Component view from a SCATE tool designer perspective. The dashed dotted line represents data type generation. The dotted line represents the generation of input files for ANTLR. Finally, the dashed line represents parser generation.

The C++ software infrastructure of SCATE has been generated using C3PO.
For parser generation ANTLR is used.
As a back-end tool for the process network generation MPC is used.

Collaboration

In addition, we are thinking about the following future challenges to which we would warmly welcome your collaboration.

Improvements in the system-level design and multiprocessor programming environment. For example, the creation of a user interface for current and future transformations.
Analysis / Transformation of Legacy or foreign code. It is a well known fact that even with high level programming languages many software implementations suffer from clarity and or quality. In this application we want to deal with these issues. For example making the control/dataflow of a program more explicit, scan for 'side effects' or any other anomalies or software constructs that may be interesting. Further on, weakly or even badly written pieces of code could be (semi) automatically transformed, thus improving on the quality of the code, for example its robustness.
Next step would be to add Software Visualization functionality to improve on the cognitive process of analyzing foreign code. In this application, software visualization data is extracted, for example software metrics, which can then be fed to a software visualization system.
Having this in place opens the possibilities of interactive software transformation. Here we make use of software visualization techniques by means of a GUI that also allows for manipulation of the graphical visualization primitives. This will result in the visualized code actually being transformed. Such an approach promises to greatly improve on many tedious software (reverse) engineering and porting tasks of legacy code.

If you would like to contribute to any of these subjects, or any other relevant subject you might think of, please drop us a line: ondrejpopp@users.sourceforge.net, dalders@users.sourceforge.net

Documentation

SCATE user manual( HTML | PDF | PS).
SCATE software infrastructure ( HTML | PDF | PS).
SCATE demos of real examples.

History

SCATE has been developed in the Triple-M project at Philips Research. Currently, the project is hosted at SourceForge.net

Publications

Pieter van der Wolf, Erwin de Kock, Thomas Hendriksson, Wido Kruijtzer and Gerben Essink, Design and Programming of Embedded Multiprocessors: An Interface-Centric Approach, CODES ISSS, Stockholm, Sweden, September 8-10, 2004.

Acknowledgment

We gratefully acknowledge the contributions to the development of SCATE from Erwin de Kock.

Finally, we thank SourceForge.net for hosting this project.

You can subscribe to the SCATE user's mailing-list. Please submit bugs, support requests, and feature requests through the SourceForge.net site.