TOC PREV NEXT INDEX DOC LIST MASTER INDEX


Statistical Profiler


This utility is available with all Rational Apex Embedded products.

The following topics are covered in this chapter:

Introduction

The Apex Statistical Profiler provides an estimate of the CPU usage by all parts of a program, including time spent in the runtime system. The profiler examines the program counter at regular intervals and keeps track of where the program is executing. Profiling shares the time-of-day timer interrupt already in use by the kernel. This makes profiling effective yet nonintrusive.

Profile a Program Using the GUI

Start in the directory viewer of the Main procedure.

1 . Set the profiling switch:

Control > Maintenance > Set Switch

Select PROFILING

Set its value to prof and click OK.

This switch selects linking with Profiling as the default for the view.

2 . Relink your program:

Select foo.2.ada

File > Link

3 . Execute the program:

Select foo.2.ada (or foo*)

File > Run

Select the Profiling button before pressing the OK button.

The file mon.out is created in your view.

4 . Display the profiling data:

Tools > Profiling

Profile a Program Using the Command-Line

The command-line invocation is apex_profile and is discussed in the Rational Apex Embedded Command Reference.

Description

The Statistical Profiler interprets the monitor file produced by the execution of a program. The symbol table of the named executable is read and correlated with the monitor file (mon.out by default). For every external symbol, the percentage of time spent executing between that symbol and the next is printed and the total time.

Call counts are not supported by this profiler.

To take advantage of the Apex runtime facilities, configure your on-board timers into the Rational runtime system. Use these regular timer interrupts to perform statistical profiling with minimal overhead.

You can control profiling behavior by changing the duration of program runs, the amount of memory allocated to profiling accounting, and the frequency of the interrupts for embedded targets.

You can run multiple programs and accumulate statistics for all runs into a single monitor file. The Statistical Profiler enables you to specify multiple executables as the source of external symbols.

How Cross-target Profiling is Done

After downloading, the invocation of File > Run with the Profiling button selected, or apex_execute with the -profile option, sets the Profile_Enabled constant in target memory to True.

V_Start_Program calls Start_Profiling at its conclusion. Start_Profiling reads the True value of Profile_Enabled and allocates and zeroes an array to contain the PC counts and installs the profile interrupt handler for incrementing PC counts.

This array of counts is constrained by the following parameters:

By default, the user program text sections are profiled with 2 Bytes_Per_Count on i386 and is 4 Bytes_Per_Count on other targets.

When a profile timer interrupt occurs, a count is incremented as follows:

This is the extent of the profile-related processing done on the target. The remainder is carried out by apex_execute and apex_profile on the host.

When the profiled program completes (either normally or with a Time_Out or Control-C interrupt), apex_execute reads the following profile configuration parameters from target memory:

Next it reads the array of PC COUNTS.

At the conclusion of reading memory, it writes the above information to the mon.out file in the current directory.

Profiling Considerations

Note: The Rational Apex Embedded Statistical Profiler does not support the Agilent Emulation Probe.

Profiling the Runtime Kernel

By default, profiling ignores time spent in the runtime system for Rational Apex Embedded for Rational Exec and Tornado. In this release of Apex, support for kernel profiling is not available. With Rational Apex Embedded for LynxOS, the runtime system is linked with the user program, and both are profiled together.

The Profiling Timer for Rational Exec

The default implementation of the profiler uses the kernel periodic timer interrupt as the trigger for incrementing the count associated with the current PC. When profiling is started, the Profile_Intr_Number configuration parameter in your Board Specific Processor view in v_usr_conf.2.ada is used as an index into the interrupt vector table for obtaining the address of the kernel timer interrupt handler. This entry is replaced with the address of the profile handler, Profiling_Isr(). At the conclusion of handling the profile interrupt, the profile handler restores the stack and registers as they were upon entry and transfers control to the kernel timer handler.

The default implementation has the following limitations:

To produce useful results in these situations, configure a second timer (if one is available on your hardware) to be your profiling timer. Set this profiling timer to interrupt at a different and faster rate than the kernel periodic interrupt timer. Be sure that the profiling timer interrupts the application at a rate which is not a multiple of the kernel periodic interrupt timer and at a rate that is greater than twice as fast as the highest frequency in the application being profiled.

Write an ISR for a different timer interrupt. If necessary, place logic to reset the timer interrupt and rearm the timer in the Process_Interrupt subprogram. Then, modify Starting_Profiling so that it places the address of this ISR in the Interrupt Vector Table using isr_attach(). If not done elsewhere, add logic for initializing the timer to Start_Profiling.

Note: If the Count_Down timer model is used, the kernel timer can not be used for profiling.

Configuring Profiling for a PowerPC Tornado Target

The tricky part about implementing profiling is figuring out where the program was (ie. what the PC register was) when the timer interrupt occurs. Unfortunately this information is not passed into the timer interrupt handler, so we have to search around on the stack for it. The good news is that the PC is there on the stack. The bad news is that its position can vary from BSP to BSP and from one Tornado release to another.

For profiling to work, you need to make sure that procedure Profiling_Isr in v_usr_conf.2.ada (in usr_conf.ss) is looking at the correct location for the PC. This location is denoted by the constant Pc_Offset defined just above procedure Profiling_Isr in v_usr_conf.2.ada. To determine the right Pc_Offset value for your setup, see item 3 below (but you should read 1 and 2 first).

We provide some tools and information in ada_examples.ss/prof to help you get profiling up and running on your board. Following is a list of what we provide.

Below is the raw output from auxclk_test on a mvme2603 board running Tornado2.

Below is the hand annotated output from auxclk_test on a mvme2603 board running Tornado2. Here is the full accounting with the value for Pc_Offset:

Configuration Options

v_usr_conf.2.ada in your Board Specific Processor view (in usr_conf.ss) contains the profiling configuration parameters and subprograms.

Example 1

The following output was generated on an Apex Embedded MIPS system. Your exact output is dependent on your target processor.

The following is an example of profiling output from apex_profile.

Example 2

You can disassemble the program using the command-line apex_profile with the –disassemble option or using the Apex Disassembler from either the GUI or command–line.

The following output was generated using the -disassemble option to apex_profile. The effect of this option is to generate a mon.list file in your current view. This file is a text file with line/time pairs, but the line information is encoded and is not directly readable.

If you disassemble the program with Compile > Show > Disassemble menu selection or the command line:

A disassembly file is generated in .Rational/Compilation with the suffix .asm.

The following corresponds to the example above. The lines "Profile percent = " present information from mon.list.

Note: If the source corresponding to a line is repeated, so is the Percentage. For example, look at the line

This generates two chunks of code.

Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS