Design Article
Comment
jonnydoin
Efficient C code for ARM devices
Chris Shore
4/2/2012 10:15 AM EDT
Originally published: ARM Technology Conference 2010, Santa Clara CA, Session ATC-152
Introduction
Our industry moves incredibly quickly. The hot topic last year is very rarely so important this year – either we will have solved it or some other issue will have risen to even greater prominence. The issue of efficiency, however, has been a relatively constant theme through my time in the industry, now some 24 years but efficiency has had many faces over that time.
In the early days, I can recall developing local area networking software on small 8-bit microcontrollers where RAM was the scarce resource. We worked long and hard to come up with cleverer and cleverer ways of storing, compressing, reusing and encoding our necessary data structures to make them fit.
Later on, I can recall a controller for a touch screen radio operator station in which the scarce commodity was code space. Limited to 32k and writing in C, the first version or two didn’t present any problems. But by the third and fourth versions, with the customer requesting added functionality all the time, we were banging hard on the ceiling of the ROM. Again, we put in the nights and weekends working out better ways of reusing common code sequences, re-coding some functions in assembler by hand to make them smaller, repartitioning the C library to remove even more unused sections.
Then there were the systems which needed to respond so quickly. There is nothing like the demand of hitting the frame rate of a time-division multiplexed cellular phone system to focus the mind on interrupt latency and processing deadlines.
These days, it seems that we very often have RAM and ROM coming out of our ears and we have processing power to burn. So what is the pressing issue of today? So often, it is power-efficiency or, perhaps more exactly, energy-efficiency. A huge proportion of today’s electronics is portable and battery-powered. We have got used to our cell phones running for a week between charges and our expectations of what they will do on that limited amount of energy goes up year on year.
Hardware engineers have been in the business of saving energy for longer than we software engineers but, increasingly, it is our job to utilize hardware features to the maximum and then realize even greater savings by writing efficient software.
The pdf of the complete article is available here.
About the author
Chris Shore, Training Manager at ARM, has 11 years of experience in training ARM's customers and end-users all over the world. He has taught and addressed conferences on every continent except Antarctica...opportunities there are limited but it is surely only a matter of time! Chris has worked in the melting pot which is the "Cambridge Phenomenon" for over 25 years. He is a Chartered Engineer and holds an MA in Computer Science from Cambridge University.
This posting is part of the EDA Designline power series and is archived and updated. The root is accessible here. Please send me any updates, additions, references, white papers or other materials that should be associated with this posting. Thank you for making this a success - Brian Bailey.
Introduction
Our industry moves incredibly quickly. The hot topic last year is very rarely so important this year – either we will have solved it or some other issue will have risen to even greater prominence. The issue of efficiency, however, has been a relatively constant theme through my time in the industry, now some 24 years but efficiency has had many faces over that time.
In the early days, I can recall developing local area networking software on small 8-bit microcontrollers where RAM was the scarce resource. We worked long and hard to come up with cleverer and cleverer ways of storing, compressing, reusing and encoding our necessary data structures to make them fit.
Later on, I can recall a controller for a touch screen radio operator station in which the scarce commodity was code space. Limited to 32k and writing in C, the first version or two didn’t present any problems. But by the third and fourth versions, with the customer requesting added functionality all the time, we were banging hard on the ceiling of the ROM. Again, we put in the nights and weekends working out better ways of reusing common code sequences, re-coding some functions in assembler by hand to make them smaller, repartitioning the C library to remove even more unused sections.
Then there were the systems which needed to respond so quickly. There is nothing like the demand of hitting the frame rate of a time-division multiplexed cellular phone system to focus the mind on interrupt latency and processing deadlines.
These days, it seems that we very often have RAM and ROM coming out of our ears and we have processing power to burn. So what is the pressing issue of today? So often, it is power-efficiency or, perhaps more exactly, energy-efficiency. A huge proportion of today’s electronics is portable and battery-powered. We have got used to our cell phones running for a week between charges and our expectations of what they will do on that limited amount of energy goes up year on year.
Hardware engineers have been in the business of saving energy for longer than we software engineers but, increasingly, it is our job to utilize hardware features to the maximum and then realize even greater savings by writing efficient software.
The pdf of the complete article is available here.
About the author
Chris Shore, Training Manager at ARM, has 11 years of experience in training ARM's customers and end-users all over the world. He has taught and addressed conferences on every continent except Antarctica...opportunities there are limited but it is surely only a matter of time! Chris has worked in the melting pot which is the "Cambridge Phenomenon" for over 25 years. He is a Chartered Engineer and holds an MA in Computer Science from Cambridge University.This posting is part of the EDA Designline power series and is archived and updated. The root is accessible here. Please send me any updates, additions, references, white papers or other materials that should be associated with this posting. Thank you for making this a success - Brian Bailey.
|
|
|
|
|
Navigate to related information
jonnydoin
4/5/2012 8:46 AM EDT
Hi Chris,
It is really interesting how that article is still valid.
When you have done the homework and selected a good low-power chip already, you must address the energy-efficiency techniques you describe to preserve your Coulombs.
Writing software thinking about Energy-Delay Product is not something that is usual, though. One has to change the way of thinking about accesses, classes and external memory.
- Jonny
Sign in to Reply