Sign In
Forgot Password?
Sign In | | Create Account

Three degrees of freedom

Developing embedded software used to be easy. Actually, that is not true. It has never been easy, but certain matters were simpler. Embedded developers have always needed more control of code generation because, as I am often heard to chant, every embedded system is different and the priorities and requirements change from one to another.

It used to be broadly a choice between speed and size of code, but it is no longer that simple …

Although embedded compilers typically offer more fine grain control, optimization of code is usually a matter of selecting a bias towards speed or size. It just works out that, most of the time, the fastest way to implement an algorithm is also biggest and the smallest is slowest. There are exceptions, but they are not so common. Much the same principle applies to data, where it can be packed [smallest] or unpacked [fastest]. This is commonly specified by a compiler optimization switch and may be overridden for specific objects using the [extension] keywords packed and unpacked.

When designing hardware, developers have a very similar choice. They code using a hardware definition language [like VHDL or Verilog] and use a synthesis tool [which is similar to a compiler] to implement the design. In the same way as with software, there are trade-offs between speed and size. However, for some time, another factor has been taken into consideration: power consumption.

As I have discussed before, power is no longer purely a hardware issue, as the software increasingly has an influence on the power efficiency of a device. Conventional code optimization has an influence on power consumption. Small code means the device needs less memory, which reduces power consumption. Alternatively, fast code causes the CPU to burn less power getting the job done. This is not an easy matter to get the balance just right. Although tools like Mentor Embedded’s Sourcery Analyzer can help, I do wonder if ” optimize for power” will soon be a compiler feature …

So, it may be concluded that instead of a two-way tension between speed and size, it now goes three ways: speed, size and power.

It occurred to me that there is an interesting analog to this situation in another technology area that interests me: digital photography. Traditionally, having selected a specific speed [i.e. sensitivity] of film [indicated by its ISO number: 100, 200, 400 etc.], for each picture the photographer needed to balance between shutter speed and aperture. This could be a problem if there was an unexpected situation when an object is moving quickly [i.e. need fast shutter speed to capture] in a circumstance where a good depth of focus [implying small aperture] is also required. Nowadays, the photographer can choose the ISO for each image – i.e. they have three degrees of freedom. Automatic cameras often let you set speed/aperture and let the other one float. I, personally, have yet to see one where both can be set and the ISO adjusted automatically to get a good exposure.

Low Power, Development Tools, Sourcery Analyzer

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 2

Post a Comment
The issue about "optimizing for power" is indeed an upcoming topic, as I have just learned from the presentations at the GNU Tools Cauldron 2013, : Embecosm have been presenting the two topics »The Impact of Different Compiler Options on Energy Consumption« as well as »MAGEEC: MAchine Guided Energy Efficient Compilation«, the latter being an industrial research project that just begun, . Surely a very ambituous project (due to the very many layers that are responsible for a computation's power consumption), but we shall wish them the best luck in this project!

Thomas Schwinge
6:38 PM Jul 18, 2013

Bah, the blog comment system stripped away the URLs that I gave in angle brackets. They are http://gcc.gnu.org/wiki/cauldron2013 and http://mageec.org/ and the compiler/toolchain this is about is GCC (but I think Embecosm are also looking into LLVM).

Thomas Schwinge
6:40 PM Jul 18, 2013

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat