About five years ago, P.J. Plauger gave a lecture at the Embedded Systems Conference entitled “Embedded Programming in C++,” which was also the subject of an article in his “State of the Art” column in this magazine.1 That was also the first Embedded Systems Conference where I presented my one-day tutorial introduction to C++. In those days, C programmers were considering C++ for embedded systems, but hardly any were actually using it.
In his lecture, Plauger explained the benefits and possible costs of switching from C to C++. He also recommended a strategy for realizing those benefits while minimizing the risks. Inasmuch as a good deal of his advice was based on the recommendations that Tom Plum and I made in our C++ Programming Guidelines ,2 I'd have to say it was pretty sound advice.
When Plauger decided to hop off the trade show ride for a while, he yielded that lecture topic to me. My presentation at the next Embedded Systems Conference bore great similarity to Plauger's. However, within a year or so, more and more people came to the lecture having already used C++. Despite the description in the conference catalog, they hoped that a lecture entitled “Embedded Programming in C++” would provide more than an overview of C++. They wanted to see specific programming techniques they could take home.
I tried to please as much of my audience as I could, but the crowd had grown too diverse. Those in the audience who didn't know C++ weren't ready to see specific techniques, and those who knew some C++ didn't need a C++ overview. So I split the one talk into two, each aimed at a more clearly defined audience. The lecture for those dipping their toes into the water became “How to Evaluate C++ as a Language for Embedded Programming.” The lecture for those who had taken the plunge became “C++ Embedded Programming Techniques.”
Well, once I clearly identified “How to Evaluate C++” as a lecture about strategies rather than specific programming techniques, it became much easier to please almost everyone in the audience. Unfortunately, the title of the other talk was still a little too broad. I found a small but vocal segment of the audience was still surprised with my selection of topics.
By the way, I had also been giving a talk entitled “Manipulating Hardware in C and C++,” which discussed ways to represent and manipulate hardware resources as C and C++ data structures. Therefore, my talk on “C++ Embedded Programming Techniques” focused entirely on techniques other than for tweaking hardware.
To appeal to the broadest possible audience, I tried to select an assortment of techniques that were platform-independent. By and large, my speaker evaluations indicated that my selections succeeded. The audiences were generally happy with the talk. However, I was still taken aback by the number of attendees who wrote on their evaluations that the techniques, while interesting, did not apply to their particular applications.
In retrospect, I shouldn't have been surprised. I knew that embedded applications were diverse. I guess I just needed a reminder, and my audiences were certainly obliging.
I decided to focus the talk a bit better. At the very least, I needed to change the title so that the attendees would get what they expected, even though many of them didn't read the abstract in the conference catalog. I guessed that even if they couldn't agree on what embedded programming was about, most of them were interested in, if not obsessed with, run-time performance. So I revised the lecture to focus entirely on performance and dubbed it “Reducing Run-Time Overhead in C++ Programs.”
This talk is based on my belief that too many embedded systems programmers use what may be legitimate concerns about the size and speed of their code as an excuse for using poor design and coding practices. This is unfortunate. I think the key to good embedded programming is to find ways to address these concerns while making as few compromises as possible.
With the possible exception of the smallest, most constrained applications, typical embedded applications are just some combination of capturing input, storing and retrieving data, performing computations, and generating output. In other words, most embedded programming is just plain programming; therefore, by and large, good embedded programming technique is just plain good programming technique.
For example, linked data structures such as lists and trees are useful in a wide range of applications. Most C programmers learn to manage the memory for linked structures using the standard functions malloc and free . A typically general implementation for malloc and free can be relatively slow–so slow that some real-time applications can't afford to use them. Some programmers use this slowness as an excuse to abandon linked structures altogether and use statically allocated global data structures instead. Unfortunately, programs with lots of global data are always brittle.
Just because an application can't afford to use the general malloc and free doesn't mean the application can't use linked structures at all. It only means the application can't manage the memory for those structures using malloc and free . The program may be able to use linked structures with a less general memory management scheme that yields acceptable performance.
In the course of writing and rewriting these lectures, I've collected numerous programming tips and techniques that I believe are of interest to at least some embedded systems programmers. Most have held up pretty well. A few were put to rest after being shot down. The purpose of this column is to explore these tips and techniques in greater detail and see if they hold up under the scrutiny of a broader audience.
I invite you to write to me to suggest improvements or variations on my themes. I'd like to know of circumstances where my suggestions do or do not apply. As we proceed, I'm hoping to gain a better sense of which techniques are most valuable to the broadest range of embedded applications. And if you have a technique you'd like to share, I'd love to consider it.
Dan Saks is the president of Saks & Associates and a contributing editor for the C/C++ Users Journal. He served for many years as secretary of the C++ standards committee. With Thomas Plum, he wrote C++ Programming Guidelines (Plum Hall, 1991). E-mail him at .
2. Plum, Tom and Dan Saks. C++ Programming Guidelines . Somers Point, NJ: Plum Hall, 1991.