Embedded Muse 80 Copyright 2003 TGG January 25, 2003

You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:- Editor’s Notes- A Fascinating Study- Jobs- Thought for the Week- About The Embedded Muse

Editor’s Notes

I wrote a three-article series in Embedded Systems Programming about watchdog timers. The first appeared this month and has generated a tremendous amount of reader feedback. So, if watchdogs and/or reliable firmware are important to you, check it out in the print edition of the magazine or at www.embedded.com.

Just after sending last month’s Embedded Muse I broke my wrist, making typing pretty much impossible. Technology to the rescue! For any of you with a similar problem, try Microsoft’s $25 Natural Multimedia Keyboard, the one with the really weird “ergonomic” shape. It has the alpha keys split into two banks, each angled away from the other. I’d always wondered how someone would use such a strange device, but in fact it’s quite natural, and made it possible – though slow – to type despite the busted bone. It’s so nice that I’ll continue using it even after the cast comes off.

A Fascinating Study

Researchers at Stanford have just released a paper detailing their use of automated tools to look for redundant code in 1.6 million lines of Linux. “Redundant” is defined as:- Idempotent operations (like assigning a variable to itself)- Values assigned to variables that are not subsequently used- Dead code- Redundant conditionals

(The authors did eliminate the oddball cases where these operations are important, like in setting memory mapped I/O.)

They found that redundancies, even when harmless, strongly correlate with bugs. Even when the extra code causes no problems, odds are high that other, real, errors will be found within a few lines of the redundant operations.

In their words “The results indicate that (1) files with redundant errors are good audit candidates and (2) redundancy correlates with confused programmers who will probably make a series of mistakes.”

Block-copied code is often suspect, as the developer neglects to change things needed for the code’s new use. Another common problem area: error handlers, which are tough to test, and are, in data I’ve gathered, a huge source of problems in deployed systems.

The authors note that their use of lint has long produced warnings about unused variables and return codes, which they’ve always treated as harmless stylistic issues. Now it’s clear that lint is indeed signaling something that may be critically important.

The study makes me wonder if compilers that optimize out dead code to reduce memory needs aren’t in fact doing us a disservice. Perhaps they should error and exit instead.

Get the study at www.stanford.edu/~engler/p401-xie.pdf.

Jobs

Thought for the Week

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

Do you need to eliminate bugs in your firmware? Shorten schedules? My one-day Better Firmware Faster seminar will teach your team how to operate at a world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and covers the unique issues faced by embedded developers. Here's information about how this class, taught at your facility, will measurably improve your team's effectiveness.