Software instrumentation

Embedded software development tools are important to all developers and a topic that I frequently discuss. The way such tools are described by vendors is interesting. For example, there might be a reference to an “optimizing compiler”. That is rather meaningless, as all compilers are optimizing to at least some degree. For an embedded compiler, the important factors are the quality of optimization and, more importantly, the degree of control that the user can apply.

Another interesting terminological issue is applied to debuggers and trace tools. They are commonly referred to as “non-intrusive” …

Most people will have heard of Heisenberg’s Uncertainty Principle. Although it has a precise meaning in the realm of quantum physics (which is well beyond the scope of this blog!), it does highlight a basic rule of life: you cannot measure something without affecting the thing that you are trying to measure; i.e. the act of measurement affects the result. This applies in a surprisingly diverse range of circumstances and has useful side benefits.

If you are an electronics designer, you may need to measure a voltage in a circuit. That measurement drains a (very tiny) current, which affects the voltage. If you measure a current, a resistance is introduced, which affects the current. To look at timings and waveforms, an oscilloscope is the standard tool. The application of the ‘scope probes, affects the capacitance of the circuit, which, in turn, may modify the timing behavior. Does all this matter? Normally, no, because the effects are so tiny that they may be ignored. Sometimes, however, the effect (of tiny timing changes) may cause the circuit to malfunction. Such a fault can be hard to track down, but it does indicate that the design is rather marginal and some work to make it more robust would be advisable.

Surprisingly, the rule applies to software as well. A debugger may use a hardware probe, which has a small effect upon the timing of the code. There may be a debug agent to facilitate “run mode” debug or extra operating system instrumentation to enable profiling. Both of these affect the size of the code and, more importantly, its real time behavior. Just like with the hardware design, the effects are likely to be tiny. However, any problems that do arise simply serve to highlight poor (i.e. fragile) design.

On a future occasion, maybe I will look at more parallels from nuclear physics, which teach useful principles. Maybe we can discuss the half life of executing software …

This entry was posted on Monday, May 15th, 2017 at 2:58 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.