iSYSTEM - Embedded Social Media Press Office

iSYSTEMTechBlog: Profiler supports now Tail Call Merge Optimizations

Since winIDEA 2011 build 47 iSYSTEM's profiler supports compiler tail merge optimizations.

What is tail call merging (tail-call optimization or tail-call elimination)?
Tail call merging is a compiler optimization used by almost all modern compilers. But many compilers provide options to suppress tail call merging.
Without tail-call merge: When calling a subroutine the caller pushes its return address on the stack and hands control to the subroutine. The very last thing the subroutine does is a pop from stack to read the caller's address and return control to this address.
With tail-call merge: When a subroutine call is the very last command to execute (in the caller's function), it´s save to jump to the start of subroutine directly without adding a stack frame and reusing the caller's stack. When the subroutine is done, it will return it's results directly to the caller.
For more information see Wikipedia/Tail-call

What are the benefits of tail-call merging?
The main benefits of tail-call merging are saving stack space which is very important on recursive function calls and saving execution time which is important for embedded applications where every microsecond might count.

How does tail-call merging affect a profiler?
For the profiler tail-call merging looks like moving the subroutine's A code into the function body of the caller's function B. In Range Mode execution in function B would be attributed to function B, instead of the optimized function A. That would lead to incorrect time measurements in the profiler.

iSYSTEM's winIDEA has now a new option. If in Profiler/Configuration the option "Tail-merge analysis" is enabled, the profiler performs analysis of tail-call merge optimizations on the fly. This analysis ensures correct measurements in the profiler, but requires a higher level of debug information quality and relies on object code analysis.
If the analysis algorithm fails, profiler session aborts. In such case the tail-call merge analysis can be disabled to revert to regular range mode. Another solution is to tell the compiler not to use tail-call merging.

Tool Qualification of iSYSTEM's Software Development and Test Tools

Today iSYSTEM presented a concept and associated tool setup enabling users of iSYSTEM tools to show proof that the deployed tools work as specified.

ISO26262 is a standard that ensures functional safety in road vehicles. Parts of this specification describe provisions that automobile suppliers and/or manufacturers must fulfill in order to “minimize the risk of systematic faults in the developed product due to malfunctions of the software tool (introduce or fail to detect errors). Hence qualification has to be accomplished for software tools used in the development and test process before the actual development starts.

To implement the standard's requirements at customer side, iSYSTEM offers organizational measures and documentation as well as a tool setup for the validation of dedicated tool functionality.

One organizational measure is for instance detailed documentation about the iSYSTEM tool development and test process. Basically it is an individual safety manual adapted to the needs of a customer and contains for example:

• Tool features-/functions descriptions that are used in a safety project
• Explanations how these functions should be used
• Manuals on the application of software and hardware, “Getting Started Guides”, etc.
• Descriptions on the system prerequisites in general and in reference to the target processor
• Descriptions on well-known workarounds for a specific micro controller 

The safety manual informs the developer how to use iSYSTEM tools for the development of safety critical applications.

If a specific function of an iSYSTEM tool has to get validated based on ISO26262, iSYSTEM provides a “Tool Pre-Qualification Kit”. This consists of reference hardware plus test cases to validate several functions of an on-chip debug and trace tool such as:

• Standard debugging and IDE functions, e.g. memory read, write, step, memory dump, download, flash programming, etc.
• Advanced debugging with trace and profiling (especially time measurements)
• Software test with code coverage and unit test

This allows iSYSTEM customers to show the proof that iSYSTEM tools perfectly fit in the context of a safety project as required by the ISO 26262 standard.

 

iSYSTEMTechBlog: Overlay Support in winIDEA

An overlay is one or more regions of program code which is copied at application start or during application execution from its load location (typically ROM memory) into RAM memory. This technique is used to:

• Enhance performance when execution from RAM is faster than from ROM
• Allow different application modules to be loaded into RAM at different times

Code in an overlay region is typically linked to its execution (RAM) address. Symbolic information can be reported a load or at exectue address.

There are two different types of overlays:

• Static overlays: Overlay region which is copied to RAM only once and stays loaded for the duration of the application.
• Dynamic overlays: If an overlay RAM region is loaded with different overlays during application lifetime, it is a dynamic overlay.

On-chip trace relies on knowing the code which is executed. A debugger will extract this information from the download file, but in an overlay system no code is loaded at the execution address.
If symbolic information is reported at execution address, debugging will work well for static overlays, but will fail for dynamic overlays, because one execution address maps into multiple overlays.

winIDEA currently supports only static overlays. Symbolic information must be reported with execution address. Overlays are Process specific. To configure them Debug/Files for Download/Process tab and edit the appropiate process.

 

iSYSTEMTechBlog: Difference between Profiler's Entry/Exit and Range Mode

Since winIDEA 2010 build 9.10.144 and winIDEA 2011 9.11.14 iSYSTEM's profiler supports the so called "Range" operation mode additional to Entry/Exit mode. Range mode should be selected when compiler optimizations make the function exit identification unsecure or impossible.

Basics: What does a profiler?
The profiler is used to identify performance bottlenecks (which function runs most often), execution time deviations (how long is a function's minimum and maximum execution time)  and invocation periods (how often does a function run).

Entry/Exit Mode:
Up to now the profiler used the so called Entry/Exit mode. In that mode the profiler is configured to record execution of instructions at a specific function's entry and exit point, and if executed, the instruction address and the time are recorded. From that above measurement values are deduced.
This method relies on accurate exit information which is best if profiler hardware has access to real-time program flow - e.g. on an ICE system with access to all buses. Because of the amount of information on ICE systems, filtering should be used to reduce the trace information.
Disadvantage of this mode is the reliance on accurate exit information. Compiler optimizations can obscure the exit information.

Range Mode:
In range mode the profiler monitors the continuous stream of program flow. If the program counter moves from one function body to another, the profiler considers this a call of a function or the return from the current function (depending on the instruction) and records the instruction address and time.
Therefore range mode is independent from function exit information.
Range mode is a stateless algorithm that makes it insusceptible to weak debug information, compiler optimizations and RTOS stack manipulations. In addition RTOS task switches are noted by execution profiler even if no data trace is available.
Disadvantage of range mode is that the complete program flow must be available which is unpractical for bus trace systems e.g. ICE.

To set range mode, open the the Hardware - Analyzer Setup and change the Profiler Operation mode to "Range" in winIDEA 2011 or "Range Analyzed" in winIDEA 2010.

For more information see  www.isystem.com.

 

iSYSTEMTechBlog: Realtime Unit Test - what's that?

Realtime unit testing runs test scripts and verifies your application without any influence on its runtime behavior.

Why is that important?
Because most unit test tools on the market instrument the application's code and install a test driver through which resource utilization and task execution is changed. Additionally the instrumented code must be compiled, linked and downloaded to the target system for every test case.

The much better approach is realtime unit testing: Realtime unit testing does not require code instrumentation or any test driver. iSYSTEM has enhanced their debug and test tools to allow the generation and execution of test cases from inside the development environment. No test driver is necessary. Without compiling/linking/download the test is executed on the real target hardware.

iSYSTEM calls that realtime unit test because the test is executed on the real hardware without any effects on the runtime behavior.

How does realtime unit test work?

First you need a working hardware that is connected by an iSYSTEM debugger (Blue Box e.g. iC5000, iC3000) the PC. Second the software must basically work to initialize the hardware and run until main().

At that point testIDEA takes over. Based on a test specification testIDEA puts the parameters for that function test on the stack – that’s the only additional resource needed by testIDEA - , executes the function in realtime, compares the return values to the expected ones specified in the test specification and returns to main().

testIDEA is a free and open programming interface (API) that is completely integrated in winIDEA. With that API set one can write test applications/cases but also auto­mati­cally execute them on the hardware connected by iSYSTEM tools. testIDEA also includes an interactive GUI for generating test cases and test reports.

For more information see:

iSYSTEM testIDEA

testIDEA: How to generate a test report?

testIDEA: Use Variables to pass Test Parameters

testIDEA: Test Tree Structure and Inheritance of Test Specifications

testIDEA: How to Collect Code Coverage Information while Testing?

testIDEA: Use Stubs to Exclude Functions from Testing

testIDEA: Run Profiler inside testIDEA to Optimize Performance

testIDEA: How to start Program and Data Trace from testIDEA

iSYSTEMTechBlog: Difference between Source and Object Code Coverage