Posts Tagged ‘optimization’

22 May, 2017

I recently came across an excellent book: The Art of Readable Code by Dustin Boswell and Trevor Foucher. As soon as I heard about the book, I knew that it would interest me and ordered a copy without delay. For years, I have pushed the message that the #1 priority, when writing code, is readability; the authors and I are on the same wavelength. I am likely to be referring to this book again in this blog, as, on initial reading, although many things are already clear and familiar to me, I still have more to learn and to share … Read the rest of this entry »

, , ,

17 December, 2012

Yesterday evening we had dinner with friends. The guy works on real time control systems and was talking about the trouble he is having with some young, well qualified engineers, who think that they know everything, even though they have very little experience of the real world. Our wives exchanged glances – they knew that he and I were on common ground, but a place outside of their world. He continued: “But they do not really understand the whole point behind writing code”. As this is a subject close to my heart, that I have written about before, I explained my view on the matter. He said “Exactly.” And, to the relief of our better halves, we moved on to other topics.

The subject of why code is written was stuck in my brain … Read the rest of this entry »

, , , , ,

3 December, 2012

Some weeks ago, I made a posting in which I presented some code and then considered how it might be optimized and asked for input from readers. I was confident that I would not have found every possibility. Indeed, there were some useful comments, which I really appreciated. [It is nice to know that there is someone out there!]

Apart from the comments, I had an email from Michael Luber in Germany, who looked at the problem in some detail. With his permission, I have reproduced his results here … Read the rest of this entry »

, , ,

19 November, 2012

I recently attended an event focused on power and embedded software hosted by the NMI in the UK, where I had been invited to make a presentation. My session was titled “Power Management in a Real Time Operating System”. If you would like a copy of the slides, please email.

Of course, apart from presenting myself, I was interested in the other sessions, in particular one about compilers and power consumption … Read the rest of this entry »

, , , , ,

6 August, 2012

Most of the time, I subscribe to the view that “the only stupid question is the one you did not ask”. However, I do have trouble with a question that I have been asked countless times at trade-shows, seminars etc. The question is “How much memory does Nucleus RTOS need?”

It is not that this is a stupid question. It is very sensible to be fully aware of resource utilization with deeply embedded systems. The problem is that I am rarely sure how to give a meaningful and useful answer, so I resort to generalities and this is often viewed with suspicion. The reason for this is that the answer is dependent upon a great many variables … Read the rest of this entry »

, , , , ,

10 October, 2011

Two weeks ago, I set a quiz. I listed four ways to write some code, which was supposed to divide an unsigned integer by 8. I commented that the priority was for the code to be as fast as possible and asked which of my lines of C was most efficient.

I was pleased with the response and acknowledge contributions from Peter Bushell, Dan S, Ken Simone, Krzysztof Wesołowski, Lee Riemenschneider, and Shaun Shippey. Between them, they picked up all the points that I had in mind and raised at least one more … Read the rest of this entry »

, , , ,

26 September, 2011

I was recently reading a set of “golden rules” for embedded programming. I am very skeptical about such proscriptive instructions as, for them to be valid, a great many assumptions must be made and clearly stated. These rules were supposed to promote the production of safe, efficient code. I am OK with “safe” – that simply means that the code does what it is supposed to do, without deviation as a result of unexpected data or unexpected side-effects. I am not so sure about “efficient”, as that depends entirely on the design parameters in force; it might mean fast or it might mean small, for example. And what about maintainability and portability being significant parameters?

So, instead of trying to outline rules myself, I thought that I might set out to find out what real developers think … Read the rest of this entry »

, , , ,

22 August, 2011

Embedded software development tools are important to all developers and a topic that I frequently discuss [like here]. The way such tools are described by vendors is interesting. For example, there might be a reference to an “optimizing compiler”. That is rather meaningless, as all compilers are optimizing to at least some degree. For an embedded compiler, the important factors are the quality of optimization and, more importantly, the degree of control that the user can apply.

Another interesting terminological issue is applied to debuggers and trace tools. They are commonly referred to as “non-intrusive” … Read the rest of this entry »

, , , , , , ,

8 August, 2011

I have frequently made the observation that a key difference between embedded and desktop system programming is variability: every Windows PC is essentially the same, whereas every embedded system is different. There are a number of implications of this variability tools need to be more sophisticated and flexible; programmers need to be ready to accommodate the specific requirements of their system; standard programming languages are mostly non-ideal for the job.

I have written on a number of occasions [like here] about the non-ideal nature of standard programming languages for embedded applications. A specific aspect that can give trouble is control of optimization … Read the rest of this entry »

, , ,

22 November, 2010

A common compiler optimization is the inclusion of a function’s code at the location(s) from where the function is called, instead of just having calls to the code located elsewhere: inlining. This provides a speed advantage, as the call/return sequence is eliminated, but may increase the memory footprint, if the function is more than a few instructions and is called more than once. I have written about this topic before, here and here.

I have an enduring interest in code generation and compiler optimizations and my consideration of inlining was piqued by a recent comment on one of my earlier posts. I realized that there are two implementation related aspects of inlining which are particularly relevant to embedded software developers … Read the rest of this entry »

, , , , ,

22 February, 2010

The idea of inlining code – placing the actual code of a small function at each call site – is a well known compiler optimization, which I have discussed before. This technique can provide significant performance improvements, due to the elimination of the call/return sequence. Also, stack usage is reduced. There is a possible cost in terms of increased program memory requirement.

It is reasonable to expect a good C or C++ compiler, when told to compile for speed, to perform inlining automatically. Some C compilers have extensions to give more control over this, but C++ has intrinsic support for inlining within the language … Read the rest of this entry »

, , , ,

11 January, 2010

Life is often about compromise, but embedded developers really are not good at that. Code generation is a context in which compromise is somewhat inevitable and we call it “optimization”. All modern compilers perform optimization, of course. Some do a better job than others. A lot of the time, the compiler simply guesses which optimization will produce the best result without knowing what the designer really wants. For desktop applications, this is OK. Speed is the only important criterion, as memory is effectively free. But embedded is different …

Read the rest of this entry »

, , , ,

10 August, 2009

If you are reading this blog, you are probably knowledgeable about embedded software and, therefore, like me, you consider yourself proficient in C. C is still the dominant language for embedded work. I read an article recently which espoused the view that “real men program in C” – I rather liked that. It also suggested that, since relatively few new graduates know C, there is an increasing shortage of expertise. This is great news for us old hands.

However, we should not be complacent. I think that I know C quite well. After all, it is quite a small language, so getting a grip should not be hard. Even aspects of it that are specifically interesting to embedded developers [and there are quite a few] should not be too difficult to master. But sometimes it is possible to get caught out …

Read the rest of this entry »

, ,

@colin_walls tweets

Follow colin_walls