Otawa  0.10
Processor Layer

The OTAWA Properties System provides a flexible and easy way to store in the program representation the result of different analyses. More...

Classes

class  otawa::BBProcessor
 This processor is dedicated to the basic block process thru proccessBB() method. More...
 
class  otawa::CFGProcessor
 This is a specialization of the processor class dedicated to CFG processing. More...
 
class  otawa::ContextualProcessor
 A contextual processor allows to process basic block in a call-aware way even with a virtual CFG (where called CFG are inlined). More...
 
class  otawa::AbstractFeature
 See Feature. More...
 
class  otawa::Feature< T, C >
 A feature is a set of facilities, usually provided using properties, available on a framework. More...
 
class  otawa::SilentFeature
 The usual Feature class has as drawback to exhibit completely the processing of the feature and therefore, in C++, to require too much header file inclusion (like the default processor or the default handler structure). More...
 
class  otawa::FunProcessor
 This is a specialization of the processor class dedicated to function processing. More...
 
class  otawa::LBlockProcessor
 This is a specialization of the processor class dedicated to LBlock. More...
 
class  otawa::Processor
 The processor class is implemented by all code processor. More...
 
class  otawa::NoProcessor
 A processor whise execution cause an exception throw. More...
 
class  otawa::UnavailableFeatureException
 This exception is thrown when an feature can not be computed. More...
 
class  otawa::Progress
 This class is an interface to get progress information about execution of a processor. More...
 
class  otawa::ProcessorException
 This class is used for returning exceptions from the processors. More...
 
class  otawa::Registry
 Class dedicated to the registering of the processors. More...
 
class  otawa::AbstractRegistration
 Abstract class to represent the registered processors. More...
 
class  otawa::p::declare
 Class to declare simple a processor. More...
 

Detailed Description

The OTAWA Properties System provides a flexible and easy way to store in the program representation the result of different analyses.

Yet, the computation of the WCET may require a lot of different analyses, it becomes wuicly difficult to handle the chaining of different analyses according their requirement.

Processor Concepts

Features

A feature represents a set of services that are available on the program representation. These services are provided either by the program loader, or by a previous analysis. These services are composed of:

  • properties linked to the program representation,
  • methods providing meaninful results in the objefct of the program representation.

The feature are an easier way to inform the framework that some services are provided and to group properties and methods in logical sets. A feature is mainly implemented by an otawa::AbstractFeature.It may be implemented by a simple otawa::Feature with a default code processor (see below) to satisfy the service if it is not provided. As the goal of feature is to share some data between analyses, it is first declared in a header file, for example "my_feature.h" :

#include "MyDefaultProcessor.h"
extern Feature<MyDefaultProcessor> MY_FEATURE;
Then, it must defined in a source file, for example, "my_feature.cpp":

#include "my_feature.h"
Feature<MyDefaultProcessor> MY_FEATURE("MY_FEATURE");
Note that a feature must have a unique name: duplicate names in features names will be detected at system startup and will cause abortion of the application. Although it is not mandatory, it is advised (1) to give a name in uppercase with underscores to separe names and (2) to give the full-qualified C++ name. This last property will help to retrieve features when dynamic module loading is used.The way proposed above to declare a feature has a drawback: it is costly in computation time as it requires the user to include the default processor class. To avoid this, OTAWA propose to use the otawa::SilentFeature class. In this cas, the header file will become:

extern SilentFeature MY_FEATURE;
The, the source file is a bit more complex as it must now design the default processor:

#include "my_feature.h"
#include "MyDefaultProcessor"
static SilentFeature::Maker<MyDefaultProcessor> MY_MAKER;
SilentFeature MY_FEATURE("MY_FEATURE", MY_MAKER);
Code Processors

A code processor performs an analysis, that is, scan the program representation, extracts some properties and provide them to the remaining analyses. To organize the properties, they are grouped logically in features. To organize this work, the code processors records themselves to OTAWA in order to:

  • ensures that the required features are available,
  • inform that the processor computes some new features.

Consequently, in OTAWA, analyses are packaged inside code processors (otawa::Processor) that manages the features but also provides other facilities:

  • configuration of the processor work,
  • control of output streams,
  • statistics gathering,
  • details about the computation
  • several classes to make analysis writing easier (CFG processor, BB processor, contextual processor and so on),
  • resource cleanup.

This class provides also a common way to invoke analyses. The configuration is perform in a property list structure:

PropList props;
CONFIGURATION_1(props) = value1;
CONFIGURATION_2(props) = value2;
...
Then, the processor object is simply created and invoked on a workspace:

MyProcessor proc;
proc.process(workspace, props);
For example, to redirect the log output of the processor and to activate verbosity, and to compute the domination in a CFG, we may do:

PropList props;
Processor::VERBOSE(props) = true;
Processor::LOG(props) = System::newFile("my_log.txt");
Domination dom;
dom.process(workspace, props);
Notice that the configuration properties are passed to all processor invoked to provided features required by the invoked processor.
Processor Registration

Code processors or analyzers can be invoked explicitly from C++ code, implicitly by requiring a feature or from a script (see Script class or owcet command). In the latter case, the processor name is used to retrieve its code and to allow to create an instance.As C++ does not provide any reflexive information to find back the constructor of a class, the code processor need to record in the main registry of OTAWA. To achieve, it must declare a static object (1) that will record itself to the main registry and (2) that provides all details of the code processor to the OTAWA framework:

  • the name
  • the version
  • required and/or used features,
  • invalidated features,
  • provided features,
  • configuration properties,
  • the constructor,
  • possibly its base processor (as a default, all processor have for base otawa::Processor).

Although this registration can be achieved in different ways, the current preferred way requires to declare, as public members, a static attribute named reg and a constructor taking an AbstractRegistration with reg as default value. The constructor definition allows to pass the actual registration of the subclass (that is including the one of the current class) to the OTAWA framework.

class MyProcessor: public BBProcessor {
public:
static p::declare reg;
MyProcessor(AbstractRegistration& r = reg): BBProcessor(r) { ... }
};
In turn, the static attribute must be declared with the details of the code processor in the source file:

p::declare MyProcessor::reg =
p::init("MyProcessor", Version(1, 0, 0))
.base(BBProcessor::reg),
.require(CFG_COLLECTED_FEATURE)
.provide(MY_FEATURE)
.make<MyProcessor>();