Benchmarking C compilers for embedded systems

Sep 19, 2011 21 Replies

"Have done": past tense. Congratulations, you've found the reason I wrote "these days" in my post.

Nor does "doing plenty" of something mean the same thing as running code "focused on" it. Yes, a lot of code, even on an 8-bitter, will have have the occasional bit of 32-bit arithmetic. But if that's the major focus of the program, then an 8-bitter is the wrong tool for the job, no matter how good the compiler might be at masking that mistake.

So? I'm still maintaining that code for several of those projects, and I'm pretty sure I'm not the only one. Sometimes the customer wants extra features crammed in the same hardware, so compiler improvements are still welcome.

If the 8 bitter can handle the 32 bit math (maybe thanks to a good compiler), and has other advantages over a 32 bit CPU (lower power, cheaper, smaller package, etc.. ), it is the *right* tool for the job.

The arithmetic is only one aspect of a wide range of engineering trade-offs. And if the compiler can effectively hide all the messy stuff, it may not even be a concern that the 8 bit target is pretty bad at it. It doesn't need to be perfect, it only needs to be good enough for the job.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required