|
3
Gordon Drive, P.O.Box 1347 Rockland, Maine 04841 U.S.A.
|
|
© 2004 Avocet Systems, Inc.
|
Call
Us Today at 207-596-7766 ("Picton Press")
|
|
Avocet Systems, Inc. : The Complete Solution for Embedded Systems
Development Tools
|
|
|
Embedded Update
Why Are C Compilers so Stupid?
Most developers have migrated from assembly language to C. This is a great thing.
However, there's no way to scientifically write an interrupt handler in C. ISRs
are very time sensitive, yet you have no idea how long a line of C will take.
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 not coding ISRs in C. Rather, this is more a rant against
he 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
(a string compare will take a varying 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.
An old software adage recommends coding for functionality first, and speed second.
Since 80% of the speed problems are usually in 20% of the code, it makes sense
to get the system working and then determine where the bottlenecks are. Unfortunately,
real time systems by their nature usually don't work at all if things are slow.
You've often got to code for speed up front.
Compilers should do more than generate binary. They should be intelligent assistants,
guiding and aiding us in our development process.
|
|
|
Products