Architecture of P INAPA

[...]

};

[...]

} // namespace pinapa

Figure 4.6: Example of generated code getting the values of data members

In a future version, it would be interesting to implement the conversion from a concrete value to an AST in the generated code itself. This way, the return value of the function would always be an AST, and this would remove the above limitation. In other words, code generation can be generic on the type of the variable, whereas function calling can not.

4.4.3 Architecture of P

PINAPAreuses code from GCC and the SystemC library (both of them in a slightly modified version), and dynamically loads the model to parse.

Some constraints must be satisfied:

• The user’s model must not depend on PINAPA’s code. We do not want to limit ourselves to models written explicitly for PINAPA.

• The modified versions of GCC and SystemC should not depend on PINAPAitself. This is not a strong requirement, but simplifies greatly the build system of PINAPA. This allows to compile and install the modified GCC and SystemC once and for all, and recompile only the heart of PINAPAwhen some modifications are done on its code. Furthermore, adding dependencies from GCC to PINAPAwould imply to modify GCC’s build system, which is extremely complex (a “bootstrap” system more than a simple “build” system actually).

• The back-end must not depend on the front end. We want PINAPAto be a library callable in the standard way: the writer of the front-end writes a program with a main function, and can call the main function of the back-end at any time.

The dependency graph must therefore be the one of Figure4.7.

To achieve this goal, function calls from the modified GCC or from the modified SystemC are done through callbacks (function pointers in C, functors in C++). The callbacks are declared and used in GCC and SystemC, and PINAPAis in charge of initializing them.

Another constraint is that we want to let the back-end execute some code before loading the model to parse (in particular, in LUSSY, the model to parse can be specified from the command line, so, command-line parsing must be done before being able to load the model). For this reason, loading the model is done at runtime using thedllibrary (dlopento load the library, anddlsymto fetch itssc_mainsymbol).

The link mechanism is presented in Figure4.8.

64/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy

4.4. Implementation of PINAPA

Model to parse

SystemC GCC

depends on module

Pinapa LusSy or others Back−end

Figure 4.7: Dependencies in PINAPA

Back−end

libTLMrun.so:

User’s SystemC model

GCC compiled as a library libfullgcc.so

Dynamic library

libsystemc.a:

modified SystemC library libpinapa.so:

The Pinapa library

Executable file or static library Uses a callback function in

Uses symbols from Dynamic link

Dynamic loading

Figure 4.8: Link Mechanism in PINAPA

Matthieu Moy Ph.D Thesis 65/190

Chapter 4. PINAPA: Extracting Architecture and Behavior Information From SystemC Models

4.4.3.2 A note on module hierarchy

SystemC provides a notion of hierarchical component. This means that an object (module, port, . . . ) can be instantiated as a sub-component of another one. While this is essential to organize the design, it has no influence on the semantics. For completeness, PINAPAkeeps a pointerparentin each object, pointing to the containing object, but other components of LUSSYwill not use it.

4.4.3.3 Function Call Graph

The resulting function call graph in PINAPAis somewhat complex (Figure4.9), but will be made clearer by the end of this section.

Function moved away from the original SystemC

(start simulation)

In the original version of SystemC, themainfunction is in the SystemC library itself (it actually does not do much more than displaying a copyright message and calling the sc_mainfunction). We have removed it from the library, considering that the main function should be written by the user (i.e., the programmer of the back-end). This is the item (1) of Figure4.9. Having themainfunction in a library can be acceptable in the case of SystemC, since it is deliberately a library which is very intrusive in the code using it (which is the reason why there is sometimes a confusion between a language and a library), but this is not acceptable in the context of a more traditional library, where the user wants tousethe library, not to be constrained by it (in particular, it is not possible to use two libraries containing amainfunction at the same time).

66/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy

4.4. Implementation of PINAPA

The call to the sc_mainfunction (and therefore the call to the PINAPA’s main function) must not return, because the elaboration phase may have allocated objects on the stack. We use therefore a callback mechanism (using a C++ functor), so the main function of the back-end should look like:

int main(int argc, char ** argv) {

// The backend is in my_callback::operator() pinapa::st_backend *callback = new my_callback();

// ...

pinapa::main(..., callback);

}

From thepinapa::mainfunction (2), we call the function that was originally themainfunction in the SystemC kernel (3), which in turn calls the pinapa::main_in_parserfunction (4), which dynamically loads and executes the user’s code (5) to elaborate the model. The call tosc_start(6) that originally started the simulation is bypassed and callspinapa::parser_start(7).

The elaboration has now been executed. We call the main function of the GCC compiler (8). We have modified GCC to call the functionpinapa_gcc_analyze_function_hook (9) in PINAPA

for each function it parses (passing the AST of this function as an argument). For each function parsed, pinapa::simcontext_decorate_process(10) searches for the corresponding process handler in

ELABandpinapa::analyze_function_body(11) runs over the AST to link SystemC primitives to their corresponding object.