Optimization

Optimization

Although the word “optimization” shares the same root as “optimal,” it is rare for the process of optimization to produce a truly optimal system. The optimized system will typically only be optimal in one application or for one audience. One might reduce the amount of time that a program takes to perform some task at the price of making it consume more memory. In an application where memory space is at a premium, one might deliberately choose a slower algorithm in order to use less memory. Often there is no “one size fits all” design which works well in all cases, so engineers make trade-offs to optimize the attributes of greatest interest. Additionally, the effort required to make a piece of software completely optimal—incapable of any further improvement— is almost always more than is reasonable for the benefits that would be accrued; so the process of optimization may be halted before a completely optimal solution has been reached. Fortunately, it is often the case that the greatest improvements come early in the process.

 

Links:

http://en.wikipedia.org/wiki/Program_optimization

http://www.tantalon.com/pete/cppopt/main.htm

http://en.wikipedia.org/wiki/Compiler_optimization

Assembly vs. C

Given a particular programming problem, what language should you use to realize the solution? Your choice could very well affect the success or failure of the project. So you’d better choose wisely.

Have you chosen the best programming language for your current embedded project? Your answer may very well depend on how the phrase “best programming language” is defined. Perhaps you’ve chosen the language that produces the most efficient code for your particular processor; or maybe you’ve selected the one that will allow you to finish the coding most quickly or with fewer bugs. Then again, maybe you–like so many of us–are just using the same language you always have.

Even considered within the narrow scope of embedded systems, the decision of what language to use to implement the solution to a given programming problem is a difficult one. Many factors must be considered and different weights given to each of them.

The factors relevant to a language decision probably include at least:

• Efficiency of compiled code
• Source code portability
• Program maintainability
• Typical bug rates (say, per thousand lines of code)
• The amount of time it will take to develop the solution
• The availability and cost of the compilers and other development tools
• Your personal experience (or that of the developers on your team) with specific languages or tools

Links: http://www.netrino.com/Connecting/2000-03/index.php

The ‘C’ test. Part – V

Data declarations
5. Using the variable a, give definitions for the following:
a) An integer
b) A pointer to an integer
c) A pointer to a pointer to an integer
d) An array of 10 integers
e) An array of 10 pointers to integers
f) A pointer to an array of 10 integers
g) A pointer to a function that takes an integer as an argument and returns an integer
h) An array of ten pointers to functions that take an integer argument and return an integer

The answers are:
a) int a; // An integer
b) int *a; // A pointer to an integer
c) int **a; // A pointer to a pointer to an integer
d) int a[10]; // An array of 10 integers
e) int *a[10]; // An array of 10 pointers to integers
f) int (*a)[10]; // A pointer to an array of 10 integers
g) int (*a)(int); // A pointer to a function a that takes an integer argument and returns an integer
h) int (*a[10])(int); // An array of 10 pointers to functions that take an integer argument and return an integer

People often claim that a couple of these are the sorts of thing that one looks up in textbooks-and I agree. While writing this article, I consulted textbooks to ensure the syntax was correct. However, I expect to be asked this question (or something close to it) when I’m being interviewed. Consequently, I make sure I know the answers, at least for the few hours of the interview. Candidates who don’t know all the answers (or at least most of them) are simply unprepared for the interview. If they can’t be prepared for the interview, what will they be prepared for

…to be continued  

The ‘C’ test. Part – IV

Infinite loops
4. Infinite loops often arise in embedded systems. How does you code an infinite loop in C?

There are several solutions to this question. My preferred solution is:

while(1)
{
ý
}

Many programmers seem to prefer:

for(;;)
{
ý
}

This construct puzzles me because the syntax doesn’t exactly spell out what’s going on. Thus, if a candidate gives this as a solution, I’ll use it as an opportunity to explore their rationale for doing so. If their answer is basically, “I was taught to do it this way and I haven’t thought about it since,” it tells me something (bad) about them.

A third solution is to use a goto :

Loop:
…
goto Loop;

Candidates who propose this are either assembly language programmers (which is probably good), or else they are closet BASIC/FORTRAN programmers looking to get into a new field.

…to be continued 

The ‘C’ test. Part – III

3. What is the purpose of the preprocessor directive #error?

Either you know the answer to this, or you don’t. If you don’t, see Reference 1. This question is useful for differentiating between normal folks and the nerds. Only the nerds actually read the appendices of C textbooks to find out about such things. Of course, if you aren’t looking for a nerd, the candidate better hope she doesn’t know the answer.

A preprocessor error directive causes the preprocessor to generate an error message and causes the compilation to fail.

A #error directive has the form:

The argument preprocessor_token is not subject to macro expansion.

The #error directive is often used in the #else portion of a #if-#elif-#else construct, as a safety check during compilation. For example, #error directives in the source file can prevent code generation if a section of the program is reached that should be bypassed.

For example, the directive
#define BUFFER_SIZE 255
#if BUFFER_SIZE < 256
#error “BUFFER_SIZE is too small.”
#endif

generates the error message:
BUFFER_SIZE is too small.

Links: 

http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc09error.htm

http://www.la.utexas.edu/lab/software/devtool/gnu/cpp/cpp_40.html 

…to be continued