Program Representation

Classes
class	otawa::Inst
	This class represents assembly instruction of a piece of code. More...
class	otawa::Manager
	The manager class providesfacilities for storing, grouping and retrieving shared resources like loaders and platforms. More...
class	otawa::Process
	A process is the realization of a program on a platform. More...
class	otawa::File
	This class represents a file involved in the building of a process. More...
class	otawa::ProgItem
	Base class of the components of a program file segment. More...
class	otawa::Segment
	In usual file format like ELF, COFF and so on, the program file is divided in segment according platform needs or memory propertes. More...
class	otawa::Symbol
	A symbol is a name of a location in a program. More...
class	otawa::WorkSpace
	A workspace represents a program, its run-time and all information about WCET computation or any other analysis. More...

Detailed Description

Description

The program representation module of OTAWA is the main module providing all details about the processed program. It provides a representation built from the program binary form (Process) and provides a workspace to perform analyses (WorkSpace). Usually, a workspace containing a process is provided by the manager (otawa::Manager) as a simple Manager::load() call:

#include <otawa/otawa.h>

using namespace elm;
using namespace otawa;

try {
  PropList props;
  Processor::VERBOSE(props) = true;
  WorkSpace *ws = MANAGER.load("path_to_file", props);
  ...
  return 0;
}
catch(otawa::Exception& e) {
  cerr << "ERROR: " << e.message() << io::endl;
  return 1;
}

The load may possibly fail and throw an otawa::Exception exception.

The Process class describes the full program and its execution environment as different items of description:

• the otawa::File represents a binary file involved in the building of the execution environments (each program has at least one file containing the main program and possibly other file for dynamically linked libraries – most often zero in embedded systems),
• the otawa::Segment divides the program in different parts (code, data, etc),
• the otawa::ProgItem decompose each segment into code or data items,
• the otawa::Inst is an instance of otawa::ProgItem that represents a single instruction,
• the otawa::DataItem is an instance of otawa::ProgItem that represents a piece of data,
• the otawa::Symbol represents a named reference on some ProgItem

To load a program, the following properties may be useful:

• otawa::TASK_ENTRY – name of the function used as entry point.
• otawa::LOADER_NAME – name of loader to use.
• otawa::CACHE_CONFIG – handle on cache configuration.
• otawa::CACHE_CONFIG_PATH – path to cache configuration.
• otawa::MEMORY_OBJECT – handle on memory configuration.
• otawa::MEMORY_PATH – path to memory configuration.
• otawa::PROCESSOR – handle on microprocessor configuration.
• otawa::PROCESSOR_PATH – path to microprocessor configuration.
• otawa::LOAD_PARAM – useful to pass a parameter to a loader in the form "ID=VALUE".

Expert users can also use the following properties:

• otawa::LOADER – handle of loader to use.
• otawa::ARGC – count of arguments passed to task on the stack.
• otawa::ARGV – null-terminated list of arguments passed to task on the stack.
• otawa::ENVP – null-terminated list of environments to task on the stack.
• otawa::NO_SYSTEM – no system is running the task.

A commonly used propertu with IPET method is the property below:

• otawa::ipet::ILP_PLUGIN_NAME – to select which to use to solve the IPET ILP system.

Notice that most properties listed above may be used with owcet Command command or most OTAWA command using "--add-prop" option. Ask for command description with "-h" option or look at otawa::Application for more details.

VLIW Support

VLIW (Very Long Instruction Word) is a technology allowing to execute in parallel several instructions, in order, without the logic needed to analyze dependencies between instructions and to re-order instructions as found in out-of-order architectures. Instruction are grouped into bundles that are guaranteed by compiler to be executable in parallel.

For instance, runned on a VLIW computer, the ARM instructions below perform actually an exchange of register R0 and R1 (end of bundle is denoted by double semi-colon):

MOV R0, R1;
MOV R1, R0;;

In fact, when the bundle above is executed, registers R1 and R0 are read in parallel and the assignment to R0, respectively to R1, is also performed in parallel.

OTAWA provides a specific support for VLIW but the bundle-aware resources can be used as is by non-VLIW instruction set: bundles will be composed of only one instruction in this case. Whatever, using bundle-aware architecture allows adaptation for free of analyzes to VLIW and non-VLIW architectures. Following bundle facilities are available:

• Inst::isBundleEnd() – end of bundle detection,
• Inst::semInsts(sem::Block&, int temp) – semantic instruction generation with temporary re-basing,
• Inst::semWriteBack() – parallel write-back generation of registers from temporaries to actual registers,
• BasicBlock::BundleIter – iterator on the bundle composing a basic block.

A special attention must be devoted to supporting semantic instruction. Model of execution of semantic instruction is purely sequential. Hence, VLIW instruction set semantic cannot be preserved if semantic instructions of machine are executed sequentially. Re-using the example of register exchange above, the straight translation into semantics will only copy R1 to R0:

MOV R0, R1
   SET(R0, R1)
MOV R1, R0
   SET(R1, R0)

A simple trick allows maintaining the current semantic instruction behavior and to adapt without effort existing analysis to VLIW: just copy write-back registers into temporaries and delay write-back to the end of execution of semantic instructions. Therefore, the semantic instructions implementing a machine instructions of a bundle need only to be concatenated and ended by write-back operations. uses these temporaries instead (our example continued):

MOV R0, R1
        SET(T1, R1)             // T1 refers to R0
MOV R1, R0                      // T2 refers to R1
        SET(T2, R0)

        SET(R0, T1)
        SET(R1, R2)

This requires the help of the VLIW instructions to build such a sequence. Usually, the template to translate into semantic instructions looks like:

MOV ri, rj
   SET(ri, rj)

For VLIW, this template must be re-defined to perform write-back on temporaries:

MOV ri, rj
        semantic
                SET(temp, rj)
        write-back (1 temporary used)
                SET(ri, temp)

Write-back sequence is obtained by a call to Inst::semWriteBack() that returns also the number of used temporaries and Inst::semInsts() allows generating the semantic instruction using a specific temporary base. To detail the example, we get:

   Inst(MOV R0, R1).semInsts(block, T1) = 1
           SET(T1, R1)
   Inst(MOV R1, R0).semInsts(block, T2) = 1
           SET(T2, R0)
Inst(MOV R0, R1).semWriteBack(block, T1) = 1
   SET(R0, T1)
Inst(MOV R1, R0).semWriteBack(block, T2) = 1
   SET(R1, T2)