Writing, programming, and debugging at Arm TechCon - Embedded.com

Writing, programming, and debugging at Arm TechCon

Greg Davis, director of engineering, compiler development, at Green Hills Software, is on the program to teach two classes at the Arm Technology Conference this week: [ATC-135] Tips and Tricks for Debugging ; and [ATC-150] Reliable Programming in ARM Assembly Language.

I always enjoy the experience when I have a chance to attend one of his classes, whether at the Arm Technology Conference or at the Embedded Systems Conference, and when, as editor on Embedded.com, I have a chance to read one of his articles submitted to me for publication.

He is both entertaining and clear in his expositions of technical detail, giving me the impression that even as a non-programmer I can understand what is going on during the software development process.

In his Tips and Tricks paper at the Arm TechCon, he gives a clear explanation of the debug process, its intricacies and the various ways he has found for developers to work through, or around, their coding problems.

But what really caught my attention were his comments about the differences and similarities between the writing a journalist like me does and the “writing” a program developer does.

“When people think about what a software engineer does for a living, they say he or she writes code,” he says. “While this is certainly true, it is hardly an accurate description of what the job is like since writing code is unlike just about every other form of writing. A journalist might write several articles in a given month on a variety of topics in his domain.

“At a high level, the process of authoring a particular article might be like the process of writing a piece of code. You might start with an outline view of the whole, then work on the key points until you arrive at a rough draft. Then you might start fixing flaws and improving on various aspects until you arrive at something that is usable.”

But, he says, this is probably where the similarity ends. “A journalist may follow such a process to write his article, then he may take a step back, do some more research, and then start over again on a new article. The next article may stand independently of his previous works. Or, as is often the case, it may build upon previous articles. Yet once an article is published, it is on the record as published, and revisions are usually limited to corrections to factual errors.”

This alone, he emphasizes, sets the world of an engineer far apart from the world of a journalist. “Except when changing jobs, very rarely is an engineer every really done with his code,” says Davis. “Typically, an engineer works on an accumulating body of code; from version to version, new capabilities are added, but much of the old code remains. The old code needs to constantly be revisited to make it work with new aspects of the evolving system.”

(Is this true in your experience as a programmer and developer? Are there other similarities and differences you can point to?)

Davis is also emphatic when he talks about the critical differences between writing and debugging code and the mindset a developer has to take on when he does the latter.

“Studies show that an engineer spends roughly 80% of his time debugging, so it is surprising how little attention is paid to this time consuming activity,” he says. “Debugging is unlike how we write code. When we write code, we start with a conceptual model of how we believe our code works, and then we augment the code to match the model of how we believe the code should work.

“The fact that our conceptual model of a program’s behavior is flawed is what leads to needing to debug in the first place. On the other hand, debugging is centered on the reality of how your program is actually behaving. Debugging is the process of discovering how things really work so that we can set them right.”

As much as I have learned technically from his paper, this brief look into the mind of a programmer doing debugging is the most important thing I brought away from it. It will inform all my thinking and writing about embedded systems development in the future.

If you don’t get the opportunity to attend this class (ATC-135), other articles Greg has written you might enjoy reading include:

Reliable programming in ARM assembly language (ATC-150),”
Guidelines for writing efficient C/C++ code,”
Compiler optimization for smaller, faster application code ,”
Tips for efficient code generation,” and,
Achieve reliable embedded code with MISRA C .”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.