What You See Is Not What You Get

Nov. 5, 2001
WYSIWIG helped define visual, "What You See Is What You Get" word processors. It also applies to debuggers. We see individual threads execute with debuggers. But what we see is not what we get: the programs may not work. Yes, we have the threads...

WYSIWIG helped define visual, "What You See Is What You Get" word processors. It also applies to debuggers. We see individual threads execute with debuggers. But what we see is not what we get: the programs may not work. Yes, we have the threads down cold. We've been doing thread-level debugging since Borland's and Microsoft's IDEs. We have it all: watchpoints, soft breakpoints, hard breakpoints, trace buffers, and so on. Some of the latest debuggers even add data displayed in graphical form.

Unfortunately, the traces often work when the program doesn't. This isn't unexpected. We create programs by the classic "divide and conquer" technique—breaking an application down into smaller and smaller subsets, down to the basic blocks, and then implementing from the bottom up.

Nice technique. But then we debug the small pieces and assume that the overall program works. Bad assumption. We do top-down design with bottom-up implementation and debug. Shouldn't we check at the program level? In fact, once the basic code runs, shouldn't we debug at the macro level, and then if something goes south, go down to the micro and find out why?

Years ago, Mitch Kapour, who created the Lotus 1-2-3 killer app, devised another program. It was a presentation package for prototyping program interfaces by defining screen sequences. Similarly, many applications can be represented as a black box displaying the program's major events.

Most applications can be characterized by their execution events. For a car motor controller, the event sequence is TDC, open the input valves, inject fuel, fire plugs, open exhaust valves, and so on. Given an RPM, the program execution can be presented as a sequence of events—in effect, a visual spec. We can use it to verify code execution at the application level. We can also use it for debugging purposes.

Today, we can see our code threads execute, but the application can still go belly up. Let's up the tool ante and debug at the program level too, so what we see is what we really get.

Sponsored Recommendations

Near- and Far-Field Measurements

April 16, 2024
In this comprehensive application note, we delve into the methods of measuring the transmission (or reception) pattern, a key determinant of antenna gain, using a vector network...

DigiKey Factory Tomorrow Season 3: Sustainable Manufacturing

April 16, 2024
Industry 4.0 is helping manufacturers develop and integrate technologies such as AI, edge computing and connectivity for the factories of tomorrow. Learn more at DigiKey today...

Connectivity – The Backbone of Sustainable Automation

April 16, 2024
Advanced interfaces for signals, data, and electrical power are essential. They help save resources and costs when networking production equipment.

Empowered by Cutting-Edge Automation Technology: The Sustainable Journey

April 16, 2024
Advanced automation is key to efficient production and is a powerful tool for optimizing infrastructure and processes in terms of sustainability.

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!