Minimize instrumentation overheads

A key challenge with on-target verification is the influence that the act of measurement itself can have on the results obtained. This is referred to as the called probe effect. For example, adding instrumentation points to the source code changes the code size, execution time, and may also increase stack usage.

In some cases, adding an instrumentation point may cause the compiler to produce different object code for other sections of essentially unchanged source code in the same sub-program. This occurs because the addition of instrumentation code can change the compiler’s use of registers leading to changes to apparently unrelated code in the same sub-program.

There are a number of possible approaches to collecting measurements that significantly curtail the probe effect:

• A logic analyzer or data logger can be set up to read and timestamp values that are written to an I/O port. Instrumentation points can then be implemented in a small number of instructions (often one or two). In this case, (where a constant value is written to a specific address) the instrumentation point is probably implemented without even a register access.
• An even better implementation can be achieved if it is possible to log which locations are executed (certain, advanced, debuggers support this type of functionality). Instrumentation can simply consist of labels in the object code (i.e. no actual machine instructions at all). The instrumentation point identifiers are then simply the locations of the object code labels. The execution trace is examined for occurrences of these labels.

Next week: Get best level of detail