Page 75 - The Art of Designing Embedded Systems

62 THE ART OF DESIGNING EMBEDDED SYSTEMS

C is more problematic. In fact, there’s no way to scientifically write
an interrupt handler in C! You have no idea how long a line of C will take.
You can’t even develop an estimate as each line’s time varies wildly. A
string compare may result in a runtime library call with totally unpre-
dictable results. A FOR loop may require a few simple integer compar-
isons or a vast amount of processing overhead.
And so, we write our C functions in a fuzz of ignorance, having no
concept of execution times until we actually run the code. If it’s too slow,
well, just change something and try again!
I’m not recommending that ISRs not be coded in C. Rather, this is
more of a rant against the current state of compiler technology. Years ago
assemblers often produced t-state counts on the listing files, so you could
easily figure how long a routine ran. Why don’t compilers do the same for
us? Though there are lots of variables (that string compare will take a vary-
ing amount of time depending on the data supplied to it), certainly many C
operations will give deterministic results. It’s time to create a feedback
loop that tells us the cost, in time and bytes, for each line of code we write,
before burning ROMs and starting test.
Until compilers improve, use C if possible, but look at the code gen-
erated for a typical routine. Any call to a runtime routine should be imme-
diately suspect, as that routine may be slow or non-reentrant, two deadly
sins for ISRs. Look at the processing overhead-how much pushing and
popping takes place? Does the compiler spend a lot of time manipulating
the stack frame? You may find one compiler pitifully slow at interrupt han-
dling. Either try another, or switch to assembly.

Despite all of the hype you’ll read in magazine ads about how
vendors understand the plight of the embedded developer, the plain
truth is that the compiler vendors all uniformly miss the boat. Mod-
em C and C++ compilers are poorly implemented in that they give us
no feedback about the real-time nature of the code they’re producing.
The way we write performance-bound C code is truly astound-
ing. Write some code, compile and run it . . . and if it’s not fast
enough, change something-anything-and try again. The compiler
has so distanced us from the real-time nature of the code that we’re
left to make random changes in a desperate attempt to get the tool to
produce faster code.
A much more reasonable approach would be to get listings
from the compiler with typical per-statement execution times. An
ideal listing might resemble